| Message ID | 20230605144812.15241-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | fbdev: Make userspace interfaces optional | expand |
Hi Thomas, Thanks for your series! Over the past few days, I have been giving this some thought, that's why I am replying only now... On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: > Add the new config option FB_DEVICE. If enabled, fbdev provides > traditional userspace interfaces in devfs, sysfs and procfs, such > as /dev/fb0 or /proc/fb. > > Modern Linux distrobutions have adopted DRM drivers for graphics > output and use fbdev only for the kernel's framebuffer console. > Userspace has also moved on, with no new fbdev code being written > and existing support being removed. > > OTOH, fbdev provides userspace a way of accessing kernel or I/O > memory, which might compromise the system's security. See the recent True, in some form... The amount of "kernel memory" that can be accessed is controlled by the fbdev driver (or by the DRM fbdev emulation). Nothing unsafe here. The I/O memory that can be accessed (if any) is controlled by the fbdev driver, and the full capabilities (e.g. DMA to random addresses) exported depend on the actual hardware. > commit c8687694bb1f ("drm/fbdev-generic: prohibit potential > out-of-bounds access") for an example. Disabling fbdev userspace IMHO that's not a good example for the point you're trying to make, but merely bad bounds checking in kernel copying code... > interfaces is therefore a useful feature to limit unecessary > exposure of fbdev code to processes of low privilegues. This actually depends on the permissions on /dev/fb*... BTW, I am wondering if it would be possible to write a DRM emulation layer on top of (basic, e.g. no MMIO, just fb) fbdev? Gr{oetje,eeting}s, Geert
Am 07.06.23 um 14:06 schrieb Markus Elfring: >> Modern Linux distrobutions have adopted DRM drivers for graphics >> output and use fbdev only for the kernel's framebuffer console. > > Would you like to avoid a typo in subsequent cover letters? Ha! It says 'distrobutions'. > > Regards, > Markus
Hi Am 07.06.23 um 10:35 schrieb Geert Uytterhoeven: [...] > > BTW, I am wondering if it would be possible to write a DRM emulation > layer on top of (basic, e.g. no MMIO, just fb) fbdev? That exists, sort of. I first posted it here: https://patchwork.freedesktop.org/series/58569/ and it has later been transformed into these conversion helpers that I have somewhere on gitlab. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert >
Add the new config option FB_DEVICE. If enabled, fbdev provides traditional userspace interfaces in devfs, sysfs and procfs, such as /dev/fb0 or /proc/fb. Modern Linux distrobutions have adopted DRM drivers for graphics output and use fbdev only for the kernel's framebuffer console. Userspace has also moved on, with no new fbdev code being written and existing support being removed. OTOH, fbdev provides userspace a way of accessing kernel or I/O memory, which might compromise the system's security. See the recent commit c8687694bb1f ("drm/fbdev-generic: prohibit potential out-of-bounds access") for an example. Disabling fbdev userspace interfaces is therefore a useful feature to limit unecessary exposure of fbdev code to processes of low privilegues. Patches 1 to 24 fix various bugs and issues in fbdev-related code. In most cases the code uses the fbdev device where is should use the Linux hardware device or someing else. Most of these patches fix existing problems and should therefore be considered in any case. Patches 25 to 29 refactor the fbdev core code. The patches move support for backlights, sysfs, procfs and devfs into separate files and hide it behind simple interfaces. These changes will allow to easily build the userspace support conditionally. Patch 30 introduces the config option FB_DEVICE and adapts the fbdev core to support it. The field struct fb_info.dev is now also optional, hence the name of the config option. Tested on simpledrm and i915, including the device handover. Future directions: With the support for disabling fbdev userspace interfaces in place, it will be possible to make mosti fbdev drivers' file-I/O code optional as well. Thomas Zimmermann (30): backlight/bd6107: Compare against struct fb_info.device backlight/gpio_backlight: Compare against struct fb_info.device backlight/lv5207lp: Compare against struct fb_info.device fbdev/atyfb: Reorder backlight and framebuffer init/cleanup fbdev/atyfb: Use hardware device as backlight parent fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup fbdev/aty128fb: Use hardware device as backlight parent fbdev/broadsheetfb: Call device_remove_file() with hardware device fbdev/ep93xx-fb: Alloc DMA memory from hardware device fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() fbdev/ep93xx-fb: Do not assign to struct fb_info.dev fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() fbdev/metronomefb: Use hardware device for dev_err() fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup fbdev/nvidiafb: Use hardware device as backlight parent fbdev/pxa168fb: Do not assign to struct fb_info.dev fbdev/radeonfb: Reorder backlight and framebuffer cleanup fbdev/radeonfb: Use hardware device as backlight parent fbdev/rivafb: Reorder backlight and framebuffer init/cleanup fbdev/rivafb: Use hardware device as backlight parent fbdev/sm501fb: Output message with fb_err() fbdev/smscufx: Detect registered fb_info from refcount fbdev/tdfxfb: Set i2c adapter parent to hardware device fbdev/core: Pass Linux device to pm_vt_switch_*() functions fbdev/core: Move framebuffer and backlight helpers into separate files fbdev/core: Add fb_device_{create,destroy}() fbdev/core: Move procfs code to separate file fbdev/core: Move file-I/O code into separate file fbdev/core: Rework fb init code fbdev: Make support for userspace interfaces configurable arch/sh/boards/mach-ecovec24/setup.c | 2 +- arch/sh/boards/mach-kfr2r09/setup.c | 2 +- drivers/staging/fbtft/Kconfig | 1 + drivers/video/backlight/bd6107.c | 2 +- drivers/video/backlight/gpio_backlight.c | 6 +- drivers/video/backlight/lv5207lp.c | 2 +- drivers/video/fbdev/Kconfig | 12 + drivers/video/fbdev/aty/aty128fb.c | 12 +- drivers/video/fbdev/aty/atyfb_base.c | 18 +- drivers/video/fbdev/aty/radeon_backlight.c | 2 +- drivers/video/fbdev/aty/radeon_base.c | 3 +- drivers/video/fbdev/broadsheetfb.c | 2 +- drivers/video/fbdev/core/Makefile | 7 +- drivers/video/fbdev/core/fb_backlight.c | 32 + drivers/video/fbdev/core/fb_devfs.c | 484 +++++++++++++++ drivers/video/fbdev/core/fb_info.c | 76 +++ drivers/video/fbdev/core/fb_internal.h | 61 ++ drivers/video/fbdev/core/fb_procfs.c | 62 ++ drivers/video/fbdev/core/fbcon.c | 1 + drivers/video/fbdev/core/fbmem.c | 594 +------------------ drivers/video/fbdev/core/fbsysfs.c | 134 +---- drivers/video/fbdev/ep93xx-fb.c | 21 +- drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 7 +- drivers/video/fbdev/metronomefb.c | 2 +- drivers/video/fbdev/nvidia/nv_backlight.c | 2 +- drivers/video/fbdev/nvidia/nvidia.c | 8 +- drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +- drivers/video/fbdev/pxa168fb.c | 2 +- drivers/video/fbdev/riva/fbdev.c | 10 +- drivers/video/fbdev/sm501fb.c | 2 +- drivers/video/fbdev/smscufx.c | 4 +- drivers/video/fbdev/tdfxfb.c | 4 +- include/linux/fb.h | 6 +- include/linux/platform_data/bd6107.h | 2 +- include/linux/platform_data/gpio_backlight.h | 2 +- include/linux/platform_data/lv5207lp.h | 2 +- 36 files changed, 859 insertions(+), 732 deletions(-) create mode 100644 drivers/video/fbdev/core/fb_backlight.c create mode 100644 drivers/video/fbdev/core/fb_devfs.c create mode 100644 drivers/video/fbdev/core/fb_info.c create mode 100644 drivers/video/fbdev/core/fb_internal.h create mode 100644 drivers/video/fbdev/core/fb_procfs.c