On Wed, Sep 01, 2021 at 11:08:10AM +0200, Javier Martinez Canillas wrote: > On 8/31/21 2:35 PM, Daniel Vetter wrote: > > On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote: > > [snip] > > >> > >> 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. > > > > Right, $subject disabled the sysfs interface but left the fbdev chardev. I can > try to do a v2 that also disables that interface but just keep the fbcon part. > > > 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. > > > > Yes, but still would be an improvement in the sense that no legacy fbdev uAPI > will be exposed and so user-space would only depend on the DRM/KMS interface. > > > 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 > > Earlier in the thread it was mentioned that an in-kernel drmcon could be used > instead. My worry with kmscon is that moving something as critical as console > output to user-space might make harder to troubleshoot early booting issues. > > And also that will require user-space changes. An in-kernel drmcon could be a > drop-in replacement though. The drmcon wouldn't be a full console, but just an emergency log renderer. See Sam's reply, he found the series again. The real attack surface reduction is in getting rid of the console/vt uapi implementation from the kernel. -Daniel > > - have a minimal emergency/boot-up log thing in drm, patches for that > > floated around a few times > > > > Interesting. Do you have any pointers for this? My search-fu failed me when > trying to find these patches. > > Best regards, > -- > Javier Martinez Canillas > Linux Engineering > Red Hat > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch