RFC: switch to uvesafb and drop openchrome in F31+

[Adam Jackson]

I'm considering changing the vesa support code in future Fedora
releases, for a few reasons. I think this will both simplify the
support burden for developers, and increase the number of supported
video configurations in practice. But it's not clear-cut, hence this
email.

The fallback video path on x86 machines is either efifb if you're
living in the future, or X's vesa driver if you're living in the past.
At this point there are only two X drivers that require userspace setup
support, vesa and openchrome. (The latter I'm also considering nerfing,
because I sincerely doubt there are any Fedora users of it; if this is
you, speak up.) Removing this code would simplify some awkward device
enumeration cases in the X server - cases which have come up in the F30
blocker list, and I would like not to be on the critical path for that
kind of thing in the future.

This would also move an 8086 emulator out of the X server to a
dedicated usermode helper. Which is nice, since X still has to run with
elevated privileges in these cases, and X hasn't exactly lacked for
CVEs.

Having done this, we would also potentially _expand_ the number of
devices we support for graphics, because we would have a vesa-backed
fbdev driver. There exist wayland servers that can display to fbdev,
but I'm not aware of any that can display directly to vesa.

But there are risks. For one, we've never tried this. uvesafb itself is
not untested - I believe you can coax ubuntu and gentoo into using it -
but we've never built it in Fedora before, so the interactions with
with our initramfs, with plymouth, and so on are only "tested" to the
extent that they're the same thing everyone else is doing.

In particular, I'm not entirely sure how well the handoff from uvesafb
to drm works in practice. From efifb to drm is fairly well tested, and
also fairly likely to be safe, because efifb does not give you any
ability to _change_ video device state. uvesafb does, and we could end
up putting the GPU in a new funky state that the drm driver doesn't
know how to handle. I suspect this is unlikely, and possible to
mitigate (by blocking uvesafb from initializing in more cases, for
instance), but it's something to be aware of.

Finally, uvesafb only supports video devices that support VBE 2.0 or
higher. In principle, X's vesa driver supports any VBE implementation
at all. I'm not convinced this is a real issue for us though. VBE 2.0
dates to 1994, and I have maybe one pre-2.0 video card in my collection
of old weird junk.

So. Pros: remove some sketchy code from a setuid program everyone has
installed, potentially lower its privilege profile, potentially enable
wayland in more scenarios. Cons: maybe lose some device support, maybe
break gfx fallback on old-firmware systems.

What do we think?

- ajax

[Ray Strode]

Hi,

You laid this out pretty nicely.  So a few questions:

1) uvesafb is only a /dev/fb driver right ? I guess it won't help with
gnome-shell,
but might help with weston?
2) I believe SimpleDRM is a drm version of uvesafb...have you considered it?
3) One thing i'm worried about is races with the real modesetting
drivers. can we avoid loading this if theres another driver that
advertises support for the pci device? does it already?
4) if you drop vesa and openchrome, maybe you could move fbdev in the
server tree like modesetting.  If you went with simpledrm instead,
maybe you could drop fbdev entirely too?

Anyway, your email makes it sound like there are more pluses than
cons, so i'm on board.

--Ray

On Tue, Apr 23, 2019 at 8:47 PM Adam Jackson <ajax(a)redhat.com&gt; wrote:
>
> I'm considering changing the vesa support code in future Fedora
> releases, for a few reasons. I think this will both simplify the
> support burden for developers, and increase the number of supported
> video configurations in practice. But it's not clear-cut, hence this
> email.
>
> The fallback video path on x86 machines is either efifb if you're
> living in the future, or X's vesa driver if you're living in the past.
> At this point there are only two X drivers that require userspace setup
> support, vesa and openchrome. (The latter I'm also considering nerfing,
> because I sincerely doubt there are any Fedora users of it; if this is
> you, speak up.) Removing this code would simplify some awkward device
> enumeration cases in the X server - cases which have come up in the F30
> blocker list, and I would like not to be on the critical path for that
> kind of thing in the future.
>
> This would also move an 8086 emulator out of the X server to a
> dedicated usermode helper. Which is nice, since X still has to run with
> elevated privileges in these cases, and X hasn't exactly lacked for
> CVEs.
>
> Having done this, we would also potentially _expand_ the number of
> devices we support for graphics, because we would have a vesa-backed
> fbdev driver. There exist wayland servers that can display to fbdev,
> but I'm not aware of any that can display directly to vesa.
>
> But there are risks. For one, we've never tried this. uvesafb itself is
> not untested - I believe you can coax ubuntu and gentoo into using it -
> but we've never built it in Fedora before, so the interactions with
> with our initramfs, with plymouth, and so on are only "tested" to the
> extent that they're the same thing everyone else is doing.
>
> In particular, I'm not entirely sure how well the handoff from uvesafb
> to drm works in practice. From efifb to drm is fairly well tested, and
> also fairly likely to be safe, because efifb does not give you any
> ability to _change_ video device state. uvesafb does, and we could end
> up putting the GPU in a new funky state that the drm driver doesn't
> know how to handle. I suspect this is unlikely, and possible to
> mitigate (by blocking uvesafb from initializing in more cases, for
> instance), but it's something to be aware of.
>
> Finally, uvesafb only supports video devices that support VBE 2.0 or
> higher. In principle, X's vesa driver supports any VBE implementation
> at all. I'm not convinced this is a real issue for us though. VBE 2.0
> dates to 1994, and I have maybe one pre-2.0 video card in my collection
> of old weird junk.
>
> So. Pros: remove some sketchy code from a setuid program everyone has
> installed, potentially lower its privilege profile, potentially enable
> wayland in more scenarios. Cons: maybe lose some device support, maybe
> break gfx fallback on old-firmware systems.
>
> What do we think?
>
> - ajax
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Marcin Juszkiewicz]

W dniu 24.04.2019 o 02:46, Adam Jackson pisze:

>  Finally, uvesafb only supports video devices that support VBE 2.0 or
>
>  higher. In principle, X's vesa driver supports any VBE implementation
>  at all. I'm not convinced this is a real issue for us though. VBE 2.0
>  dates to 1994, and I have maybe one pre-2.0 video card in my
>  collection of old weird junk. 
Pure curiosity: which gpus are in any use nowadays?
Other than AMD,
Intel, NVidia ones.

Probably some server onboard ones only. Lot of graphic cards got dropped
in past already. Matrox ones for example.