From: P J P <ppandit@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Gaoning Pan <pgn@zju.edu.cn>, Gerd Hoffmann <kraxel@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] ati: mask x y display parameter values
Date: Tue, 20 Oct 2020 18:38:20 +0530 (IST) [thread overview]
Message-ID: <nycvar.YSQ.7.78.906.2010201810120.1506567@xnncv> (raw)
In-Reply-To: <d43d9494-72c3-eb52-4588-d324f2857c45@eik.bme.hu>
+-- On Tue, 20 Oct 2020, BALATON Zoltan wrote --+
| The card has 32 bit registers with values in them interpreted differently for
| different regs. For dst_x|y lower 14 bits can be set and value should be
| interpreted as -8192:8191 according to docs. I've got this wrong because all
| guests I've tried did not actually use negative values. The Solaris driver I
| was recently shown not to work may use that so I plan to look at it and fix it
| when I'll have time.
...
| Docs aren't very clear on that but I think these cannot be negative so
| 0:8191 is valid range because it mentions that also bits 0-13 (or maybe
| 0-15, the docs have a lot of copy&paste errors) are valid but only 0-12 are
| used for rectangles, 13-15 used only for trapezoids (which we don't
| emulate). The docs are really bad so we have to guess and see what guest
| drivers do most of the time.
* I see. Are the docs available/accessible online?
| > dst_y(=4294950914(=-16382)) + s->regs.dst_height(=16383)) overflows to => 1
| > Ie. (dst_bits + dst_x(=0) + (1) * dst_stride >= end) returns false.
|
| So maybe we should cast something (like dst_stride) to uint64_t here to
| promote everything to 64 bit and prevent it overflowing which then should
| catch this as well?
...
| > + if (dst_x > 0x3fff || dst_y > 0x3fff || dst_bits >= end
| > + || dst_bits + dst_x + (dst_y + s->regs.dst_height)
| > + * dst_stride >= end) {
| > ...
| > + if (src_x > 0x3fff || src_y > 0x3ff || src_bits >= end
| > + || src_bits + src_x + (src_y + s->regs.dst_height)
| > + * src_stride >= end) {
| > qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
|
| I can live with that until I have a chance to rewrite it but are you sure this
| will catch all possible overflows with all vram sizes that can be set with
| vgamem_mb property?
* Considering all fields are 'uint32_t' type; And majority of the values
s->regs.[src|dst]_[xy], s->regs.dst_height are masked with '0x3fff', it
should help to avoid overflows.
* Not sure about all vram sizes. What are possible/supported size options?
* Between casting expression to 64 bits & explicit src_[xy] > 0x3fff check,
I'd go with explicit check, as it's easy to follow.
Will send a revised patch with src_[xy] > 0x3fff if it's okay with you.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
prev parent reply other threads:[~2020-10-20 13:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-18 12:08 [PATCH] ati: mask x y display parameter values P J P
2020-10-18 13:58 ` BALATON Zoltan via
2020-10-19 6:27 ` P J P
2020-10-19 18:26 ` BALATON Zoltan via
2020-10-20 7:11 ` P J P
2020-10-20 11:29 ` BALATON Zoltan via
2020-10-20 13:08 ` P J P [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YSQ.7.78.906.2010201810120.1506567@xnncv \
--to=ppandit@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=kraxel@redhat.com \
--cc=pgn@zju.edu.cn \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).