linux-kernel - Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e6fff69b09b36cbdd96499cd0015154.squirrel@mail.panix.com>
Date:   Wed, 12 Apr 2023 19:13:35 -0400
From:   "Pierre Asselin" <pa@...ix.com>
To:     "Javier Martinez Canillas" <javierm@...hat.com>
Cc:     "Pierre Asselin" <pa@...ix.com>,
        "Jocelyn Falempe" <jfalempe@...hat.com>,
        "Daniel Vetter" <daniel.vetter@...ll.ch>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        "Hans de Goede" <hdegoede@...hat.com>,
        "Thomas Zimmermann" <tzimmermann@...e.de>,
        "Ard Biesheuvel" <ardb@...nel.org>
Subject: Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is
 calculated

(Okay, can't back out *all* of the first patch, just the assignment
to mode->stride.)

Anyway, here you go:

grub: gfxpayload=keep
[    0.003333] Console: colour dummy device 128x48
[    0.003333] printk: console [tty0] enabled
[    0.419983] fbcon: Taking over console
[    0.516198] pci 0000:01:05.0: vgaarb: setting as boot VGA device
[    0.516229] pci 0000:01:05.0: vgaarb: bridge control possible
[    0.516253] pci 0000:01:05.0: vgaarb: VGA device added:
decodes=io+mem,owns=io+mem,locks=none
[    0.516288] vgaarb: loaded
[    3.343649] simple-framebuffer simple-framebuffer.0: framebuffer at
0xd8000000, 0x300000 bytes
[    3.343687] simple-framebuffer simple-framebuffer.0: format=r8g8b8,
mode=1024x768x24, linelength=4096
[    3.344199] Console: switching to colour frame buffer device 128x48
[    3.681177] simple-framebuffer simple-framebuffer.0: fb0: simplefb
registered!

[    3.343345] sysfb: si->lfb_depth 32 si->lfb_width 1024
[    3.343372] sysfb: si->red_size 8 si->red_pos 16
[    3.343392] sysfb: si->green_size 8 si->green_pos 8
[    3.343413] sysfb: si->blue_size 8 si->blue_pos 0
[    3.343433] sysfb: si->rsvd_size 0 si->rsvd_pos 0
[    3.343453] sysfb: bits_per_pixel 24 si->lfb_linelength 4096
[    3.343476] sysfb: stride 3072
[    3.343493] sysfb: format r8g8b8

So it's the rsvd_size and rsvd_pos that are bogus.  The fix would be to:
  1) believe si->lfb_depth
  2) fill with ones a bitmask of size si->lfb_depth
  3) clear chunks of bits based on si->{red,green,blue,rsvd}_{size,pos}
  4) printk if the bitmask is not all zeros
  5) override rsvd_{size,pos} based on the bitmask
That way you know where the 'x' goes in xrgb.

Hm.  Could that fix my two boxes but cause a regression for someone else ?
What if _depth is low but the rsvd_ are right ?
Then _width and _linelength would be inconsistent with _depth but
consistent with the recomputed bits_per_pixel ?  How many ways can the
firmware lie ?

We need more testers, don't we ?