On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote: > Hello Daniel and Thomas, > > On 8/27/21 10:20 PM, Daniel Vetter wrote: > > On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas: > >>> This patch series splits the fbdev core support in two different Kconfig > >>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to > >>> be disabled, while still using fbcon with the DRM fbdev emulation layer. > >> > >> I'm skeptical. DRM's fbdev emulation is not just the console emulation, it's > >> a full fbdev device. You can see the related device file as /dev/fb*. > >> Providing the file while having CONFIG_FB disabled doesn't make much sense > >> to me. I know it's not pretty, but it's consistent at least. > >> > >> If you want to remove fbdev, you could try to untangle fbdev and the console > >> emulation such that DRM can set up a console by itself. Old fbdev drives > >> would also set up the console individually. > > > > Yeah given the horrendous security track record of all that code, and the > > maze of handover we have (stuff like flicker free boot and all that) I'm > > wondering whether typing a new drmcon wouldn't be faster and a lot more > > maintainable. > > > > We talked about a drmcon with Peter Robinson as well but then decided that a > way to disable CONFIG_FB but still having the DRM fbdev emulation could be a > intermediary step, hence these RFC patches. > > But yes, I agree that a drmcon would be the proper approach for this, to not > need any fbdev support at all. We will just keep the explicit disable for the > fbdev drivers then in the meantime. I think the only intermediate step would be to disable the fbdev uapi (char node and anything in sysfs), while still registering against the fbcon layer so you have a console. But looking at the things syzbot finds the really problematic code is all in the fbcon and console layer in general, and /dev/fb0 seems pretty solid. I think for a substantial improvement here in robustness what you really want is - kmscon in userspace - disable FB layer - ideally also disable console/vt layer in the kernel - have a minimal emergency/boot-up log thing in drm, patches for that floated around a few times Otherwise it feels a bit like we're just doing Kconfig bikeshedding and no real improvement on the attack surface :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
