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