Re: [PATCH] ati: mask x y display parameter values

[BALATON Zoltan via <qemu-devel@nongnu.org>]

Hello,

On Tue, 20 Oct 2020, P J P wrote:
> +-- On Mon, 19 Oct 2020, BALATON Zoltan wrote --+
> | On Mon, 19 Oct 2020, P J P wrote:
> | >    dst_x = ... (s->regs.dst_x(=0) + 1 - s->regs.dst_width(=16383))
> | >    dst_y = ... (s->regs.dst_y(=0) + 1 - s->regs.dst_height(=16383))
> | >
> | >  ati_2d_blt
> | >    pixman_blt(0x7f03cbe00000, 0x7f03cbe00000, 131064, 131064, 32, 32,
> | >       src_x=0, src_y=-16382, dst_x=0, dst_y=-16382, 16383, 16383)
> | >
> | > Shown as negative values due to signed '%d' conversion.
> |
> | Checking the docs again I see that the allowed range of at least
> | s->regs.[src|dst]_[xy] can actually be negative (-8192:8191)
>
> * But 'struct ATIVGARegs' declares these fields as 'uint32_t' type. Ie. no
>  negativeve values.

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.

> * I guess that range applies to src->regs.dst_[width|height] too? Considering
>  it being subtracted from s->regs.dst_[xy] values above.

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.

> | >    uint8_t *end = s->vga.vram_ptr + s->vga.vram_size;
> | >    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) *
> | >    dst_stride >= end) {
> | >        qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
> | >        return;
> |
> | ... Could it be it overflows?
>
> * Yes, following expression
>
>  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?

> | maybe rather add additional term for src|dst_x|y to the already existing
> | checks if their condition cannot be fixed to detect it properly.
> ===
> diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c
> index 524bc03a83..5fa7362305 100644
> --- a/hw/display/ati_2d.c
> +++ b/hw/display/ati_2d.c
> @@ -54,9 +54,9 @@ void ati_2d_blt(ATIVGAState *s)
> ...
> -    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) *
> -        dst_stride >= end) {
> +    if (dst_x > 0x3fff || dst_y > 0x3fff || dst_bits >= end
> +        || dst_bits + dst_x + (dst_y + s->regs.dst_height)
> +         * dst_stride >= end) {
>         qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
>         return;
>     }
> ...
> -        if (src_bits >= end || src_bits + src_x +
> -            (src_y + s->regs.dst_height) * src_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");
>             return;
>         }
> ===
>
> * Does it look okay?

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?

Regards,
BALATON Zoltan