Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

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:

quoted

On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:

quoted

Hi

Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:

quoted

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