graphics related options #38
Comments
Is this comment from CONFIG_VT wrong then? |
|
This comment hasn't been updated since decades (I checked historical trees ...). Nowadays Xorg and wayland compositors should be able to run without a VT. And kmscon (although abandoned due to lack of interest) can provide you a userspace implementation of VTs if you don't want to run X11 or wayland, using pseudo TTYs (like a terminal emulator). A paranoid desktop distro imo should really not have VT enabled, and ofc whatever compositor they opt for (wayland, X11, or something like kmscon) needs to be walled in with a container. But the comment is also correct in that without a userspace compositor you indeed will only be able to log in through the network or serial lines. |
|
Maybe an addition: If you want multi-user switching without CONFIG_VT then you need something like systemd's logind, so that the (forced) handover of input and output devices works correctly. But the VT subsystem's only role there is as an rpc between compositors, it has 0 functionality to actually force compositors to hand over devices to the next compositor (which is what logind does, using some of the new ioctl calls added specifically for this for both input and drm subsystems). So if you want actual secure multi-user switching then you should be running with all that new stuff already anyway (and then CONFIG_VT really shouldn't be enabled, to prevent creating a mess). |
|
Thanks, looks neat. Hopefully this pushes a few more people to make this happen finally. |
|
@a13xp0p0v Are these enabled in any distros for which you have canned configs? @danvet I just noticed on the current upstream HEAD: So that may be the first step :) |
|
@dvyukov, yes, these are enabled in many distributions: |
|
The hyperv framebuffer driver came up on the mailing list recently when I noticed a patch to add support for arm64 and suggested having it converted to DRM. Other hardware-independent drivers that don't seem to have a DRM counterpart at the moment are the UEFI framebuffer that is often used in the absence of a hardware specific driver and the goldfish driver for Android device emulation. It might help to also look at each distro to see which device drivers are enabled for DRM_LEGACY and FBDEV, as there may be others that are important and need to be converted. |
|
@dvyukov the trouble is you'll break pretty much any general purpose distro with this stuff disabled. Iirc most compositors keel over if they can't open a vt (but they should all have options to survive without one). Plus since neither kmscon nor system-consoled ever happened for real no kernel console without these, so all the whitebeards will be screaming with their pitchforks. Really not something you can do in a defconfig unfortunately. @arndb yeah there was simpledrm also back around kmscon to make this happen, but it didn't. For everything else we seem to have a small community of people now pushing out drm drivers for all these things, but more is always welcome. A drm driver in less that 1kloc is fairly standard nowadays, trouble only happens if you have a strange new constraint. Wrt DRM_LEGACY and FBDEV drivers in general, I get the impression that distros which enable them just enable everything, because. E.g. debian still enables DRM_LEGACY, but they long ago stopped shipping the corresponding userspace drivers. So just plain nonsense in their defconfig (and a CVE when you load drm/nouveau.ko because backwards compat) |
See a13xp0p0v/kernel-hardening-checker#38 Change-Id: I474c701247798605989183b27ab78bf1b2f55c03 Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
This currently gets enabled as generate-config.pl will enable all the drivers below it as modules. Is “not set” in [Arch][1], [Debian][2], [Fedora][3]. See also [summary of setting from various distros in April 2020][4]. Recommended disabled by [CLIP OS][5] and per current [Kernel config description][6]: > bool "Enable legacy drivers (DANGEROUS)" > Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous > APIs to user-space, which can be used to circumvent access > restrictions and other security measures. For backwards compatibility > those drivers are still available, but their use is highly > inadvisable and might harm your system. > > You are recommended to use the safe modeset-only drivers instead, and > perform 3D emulation in user-space. > > Unless you have strong reasons to go rogue, say "N". Also disable NOUVEAU_LEGACY_CTX_SUPPORT, as this does `select DRM_LEGACY`. Per Kernel config docs: >There was a version of the nouveau DDX that relied on legacy > ctx ioctls not erroring out. But that was back in time a long > ways, so offer a way to disable it now. For uapi compat with > old nouveau ddx this should be on by default, but modern distros > should consider turning it off. and the [commit][7]: > These driver functions contain several bugs and security holes. This > change makes these functions optional can be turned on by a setting, > they are turned off by default for modeset driver with the exception of > the nouvea driver that may require them with an old version of libdrm. Referenced earlier commit elaborates that > libdrm_nouveau before 2.4.33 used contexts Since nixpkgs here has a much newer version (2.4.33 is from March 2012), should not be a concern. NOUVEAU_LEGACY_CTX_SUPPORT is also “not set” in the linked Arch, Debian, & Fedora configs. [1]: https://github.com/archlinux/svntogit-packages/blob/66d72ee54afc604391b618fc3eecc43f29e479e8/trunk/config#L6637 [2]: https://salsa.debian.org/kernel-team/linux/-/blob/07731f5956cf29876a7abc13f4ecbdf4d9459592/debian/config/config#L713 [3]: https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config#_1528 [4]: a13xp0p0v/kernel-hardening-checker#38 (comment) [5]: https://docs.clip-os.org/clipos/kernel.html#configuration [6]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/Kconfig#n421 [7]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b30a43ac7132cdda833ac4b13dd1ebd35ace14b7
a13xp0p0v
added
the
kernel_maintainer_feedback
Discussion with dmitry yukov on twitter:
CONFIG_DRM_LEGACY: Really old drivers from the 90s, with unfixable by design security holes. Unfortunately userspace for one modern driver (drm/nouveau) has used until just a few years ago by accident (we didn't delete all the old legacy driver setup code), so can't remove it all completely yet from kernel sources.
CONFIG_FB: Old display subsystem from the 90s, essentially unmaintained for over 10 years, would need serious effort to get up to speed with modern security best practices. This even includes the minimal fbdev emulation support built on top of drm gpu drivers, since the issues are in core fbdev code.
CONFIG_VT: Maybe the most disputed of all, but a lot of the console drivers this exposes to userspace are also from the 90s, and without CONFIG_FB this isn't really useful even for a desktop. A hardened distro definitely wants to make sure this is not set at all.
The text was updated successfully, but these errors were encountered: