Arch Linux

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".


This is what upstream says itself about this config. so i object to enabling it.

Yes I feared that answer. I'm not sure if the possible security issues are within the legacy drm, or within the actual video drivers. If it's the former case it's understandable to not enable it by default. But if it's within the video drivers, then just enabling the CONFIG_DRM_LEGACY should not hurt, provided there are no drivers compiled by default using that legacy framework. That would let the choice to the user who really wants/needs to use one of those legacy drivers to still do so, without requiring to recompile its own complete kernel.

Im not an expert at all regarding that topic. I'm trying to find the best solution on how to keep those(one in particular in fact) legacy drm drivers working.

it is basically the design of those legacy drm api's and how they interact with user space. "just" enabling that config without any in-tree drivers will still result in a lot of general purpose drm structs to expose additional data and pointers plus a multitude of registered ioctl functions. The attack surface needs to simply be cut out to leverage any real advantage from freeing the subsystem of that functionality.

My humble opinion: Your best shot will be to remain on linux-lts until the next tls tree is declared and then potentially maintain a repository for people that are in need of such a kernel.

Ok, a separate repo will probably be what's going to happen. This issue can be closed I think. Thanks for the quick replies.