linux-kernel - Re: Regression: firmware/sysfb.c device path

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: <1eb659d8-536e-401b-a427-19709a98953a@suse.de>
Date: Mon, 15 Jul 2024 08:44:50 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Tj <tj.iam.tj@...ton.me>, Marek Olsak <Marek.Olsak@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "1075713@...s.debian.org" <1075713@...s.debian.org>
Subject: Re: Regression: firmware/sysfb.c device path

Hi

Am 13.07.24 um 19:20 schrieb Tj:
> The recent commits to add the parent device path broke Debian's kvm based QA workers for testing installer ISOs after a kernel upgrade from v6.8.12 to v6.9.7. For the details:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075713
>
> It took some time to  track it down since the superficial symptom appeared to involve the QXL driver. It turned out however to be the fbdev driver; specifically the change in the parent device path in sysfs reported between the two kernels:
>
> 6.8.12:
>
> /sys/class/graphics/fb0 -> ../../devices/platform/vesa-framebuffer.0/graphics/fb0
>
> 6.9.7:
>
> /sys/class/graphics/fb0 -> ../../devices/pci0000:00/0000:00:01.0/vesa-framebuffer.0/graphics/fb0
>
> This breaks xserver-xorg-core's libfbdevhw.so because it differentiates code-paths based on whether "devices/pci" is matched in the symlink.
>
> See hw/xfree86/fbdevhw/fbdevhw.c::fbdev_open()
>
> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/fbdevhw/fbdevhw.c?ref_type=heads#L381

Amazing debugging skills!

The patch that causes the regression in X sets the PCI device as parent 
for the VESA framebuffer. That means that the PCI device won't be 
unplugged or suspended while the VESA framebuffer is still in use. 
Without, results are undefined.

Therefore, could this be fixed in X' fbdev driver?

It currently tests against the sysfs path of the fbdev device. A fix 
could look like this:

  1) readlink /sys/class/graphics/fb0/device/subsystem 2) strcmp to 
"bus/pci" fb0 is the fbdev device fb0/device/ is the Linux device (the 
VESA/EFI framebuffer or native PCI graphics device) fb0/device/subsystem 
is the Linux devices' subsystem.

The subsystem string is the path to the underlying bus. For PCI graphics 
cards it's something like

../../../bus/pci

and for VESA/EFI framebuffer devices it's

../../../bus/platform

That's more correct, reliable and also keeps the correct organization of 
the devices within the kernel.

Best regards
Thomas

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)