Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 05:09 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? The KMS driver only supports the g200 cores embedded in some server chipsets, it doesn't handle real hardware. We've already dropped 3D support for those chips, though, so it's arguably not of great importance. The only real difference in functionality by dropping -mga would be losing multihead support, and I don't think anyone ever made that work on the UMS driver without the HAL blob. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. The binary drivers don't need iopl(), so the only real question is whether they need root for anything else. It may just be permissions on device nodes, in which case we can probably just special-case them? Probably. TBH I'm not that interested in the binary drivers I know the nvidia one is actually quite decent and it has a lot of users. So I don't want to break them, but beyond that my interest stops. I assume they are still not exporting any kms API to userspace, so the helper I've in mind should just launch X as root for them and then things should just keep working. I know lots of shoulds ... It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. I don't see it being any harder than the blacklisting of nouveau/radeon that's already required. Well that can be done through a config file, this would require doing a chmod on the Xorg binary which would need to be redone after every update. This assumes that if we go the uvesafb route we completely remove the helper to launch Xorg as root. Then again as you've indicated above they may not need root at all and a couple of udev rules to open the right /dev/foo nodes to console users might be enough. And then we could simply forget about supporting ums at all I guess. That would be certainly be a glorious flying-car future. Yep, I think it is probably more realistic to go for the helper first though. I'm going to send a mail to xorg-devel to see how crazy people there think it is to turn uvesafb into a kms driver. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 07:19 PM, Andrew Lutomirski wrote: On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. Or do you mean the older pre-uvesafb driver? [1] http://dev.gentoo.org/~spock/projects/uvesafb [2] http://lxr.free-electrons.com/source/Documentation/fb/uvesafb.txt Thanks for this info. It does indeed some not that widely used / tested atm. But if we change it to a kms driver an ship it by default that would certainly change. As for v86d, if I google for just v86d the first hit is: http://packages.ubuntu.com/lucid/v86d And that still has a link to a tarbal with sources. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mo, 2014-01-20 at 15:58 +, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) qemu is covered pretty well. There are cirrus + qxl kms drivers for quite some time already. kms driver for '-vga std' is in -next and will probably land in 3.14. Only missing is vmware, where the qemu emulation is to old or to buggy or both for the needs of the vmgfx kms driver. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Tue, 21.01.14 09:26, Hans de Goede (hdego...@redhat.com) wrote: Probably. TBH I'm not that interested in the binary drivers I know the nvidia one is actually quite decent and it has a lot of users. So I don't want to break them, but beyond that my interest stops. I assume they are still not exporting any kms API to userspace, so the helper I've in mind should just launch X as root for them and then things should just keep working. I know lots of shoulds ... I never used that closed source crap myself, but I just wanted to mention that some Suse folks did some work on logind to do ACL management for the nvidia device nodes even though these device nodes do not appear in the Linux device model as used by udev (simply because the device model is only available to free code). Not sure if this fixes the whole problem, but there's at least a way to manage access to some nvidia bits for unprivileged userspace. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RFC: what to do with ums when the X server is not suid root ?
Hi All, As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do rpm -e xorg-x11-server-suid-helper I'm not 100% sold on my own idea yet. The whole idea of dropping the suid bit is to remove the rather large attack surface the xserver offers. With the helper for people running kms that attack surface is reduced to a quite small, easily audited helper. But for people without kms nothing changes. On x86 most users will fall in the with kms category, but what about ie ARM? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do rpm -e xorg-x11-server-suid-helper I'm not 100% sold on my own idea yet. The whole idea of dropping the suid bit is to remove the rather large attack surface the xserver offers. With the helper for people running kms that attack surface is reduced to a quite small, easily audited helper. But for people without kms nothing changes. On x86 most users will fall in the with kms category, but what about ie ARM? At the moment on ARM most devices that have X use the xorg-x11-drv-modesetting driver which I believe uses the KMS kernel drivers so I'm presuming we'll be OK on that front. The other two that are in use are xorg-x11-drv-armsoc (currently supported via the DRM_EXYNOS module, in theory can support other Mali GPUs) and xorg-x11-drv-omap (DRM_OMAP) which I believe also use the equivalent KMS drivers but I might be wrong there. Moving forward I can't see any new ARM devices not supporting KMS as I doubt they'll get accepted into the mainline kernel without it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 10:16 AM, Peter Robinson wrote: As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do rpm -e xorg-x11-server-suid-helper I'm not 100% sold on my own idea yet. The whole idea of dropping the suid bit is to remove the rather large attack surface the xserver offers. With the helper for people running kms that attack surface is reduced to a quite small, easily audited helper. But for people without kms nothing changes. On x86 most users will fall in the with kms category, but what about ie ARM? At the moment on ARM most devices that have X use the xorg-x11-drv-modesetting driver which I believe uses the KMS kernel drivers so I'm presuming we'll be OK on that front. The other two that are in use are xorg-x11-drv-armsoc (currently supported via the DRM_EXYNOS module, in theory can support other Mali GPUs) and xorg-x11-drv-omap (DRM_OMAP) which I believe also use the equivalent KMS drivers but I might be wrong there. Moving forward I can't see any new ARM devices not supporting KMS as I doubt they'll get accepted into the mainline kernel without it. So maybe we should not build, nor install, the helper for ARM at all ? We likely either have kms or in some (respin) cases fbdev there neither of which will need root rights. And the same likely goes for other non x86 archs, so maybe the helper should be an x86 only thing, for vesa (or other ums driver) support on oddball + very new cards ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:08 AM, Hans de Goede hdego...@redhat.com wrote: Hi All, As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do rpm -e xorg-x11-server-suid-helper That will break badly for upgrades. If someone is using a ums driver, upgrades and nothing pulls in the helper he / she will end up with a broken setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 11:29 AM, drago01 drag...@gmail.com wrote: On Mon, Jan 20, 2014 at 10:08 AM, Hans de Goede hdego...@redhat.com wrote: Hi All, As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do rpm -e xorg-x11-server-suid-helper That will break badly for upgrades. If someone is using a ums driver, upgrades and nothing pulls in the helper he / she will end up with a broken setup. (sent to eerily). So we should just let ums drivers require it. (Because they technically do require it after all). A user that does not use ums drivers can still remove (along with the drivers). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. And then we could simply forget about supporting ums at all I guess. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? The KMS driver only supports the g200 cores embedded in some server chipsets, it doesn't handle real hardware. We've already dropped 3D support for those chips, though, so it's arguably not of great importance. The only real difference in functionality by dropping -mga would be losing multihead support, and I don't think anyone ever made that work on the UMS driver without the HAL blob. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. The binary drivers don't need iopl(), so the only real question is whether they need root for anything else. It may just be permissions on device nodes, in which case we can probably just special-case them? It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. I don't see it being any harder than the blacklisting of nouveau/radeon that's already required. And then we could simply forget about supporting ums at all I guess. That would be certainly be a glorious flying-car future. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 03:58:23PM +, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) We have KMS support for the qemu cirrus, so you can just use -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Isn't -cirrus still used by virt in a number of cases? I know -mga is used as a gpu chipset on a number of relatively new server platforms. What about -vmware? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, 2014-01-20 at 15:58 +, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) I mean, I've crashed the hypervisor with both... - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 8:50 AM, Peter Robinson pbrobin...@gmail.com wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Isn't -cirrus still used by virt in a number of cases? I know -mga is used as a gpu chipset on a number of relatively new server platforms. What about -vmware? I have several recent servers with MGA (compatible?) chips, and they all work fine with mgag200 (i.e. KMS). --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. Or do you mean the older pre-uvesafb driver? [1] http://dev.gentoo.org/~spock/projects/uvesafb [2] http://lxr.free-electrons.com/source/Documentation/fb/uvesafb.txt And then we could simply forget about supporting ums at all I guess. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:19:30AM -0800, Andrew Lutomirski wrote: Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. Or do you mean the older pre-uvesafb driver? That's problematic from the You have to provide a fixed resolution on the kernel command line perspective. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:50:09PM +, Peter Robinson wrote: Isn't -cirrus still used by virt in a number of cases? I know -mga is used as a gpu chipset on a number of relatively new server platforms. What about -vmware? Virt can use the cirrus kms driver, the server matrox is supported by mgag200 and doesn't the vmwgfx driver cover vmware? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Jan 20, 2014 at 10:19:30AM -0800, Andrew Lutomirski wrote: Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. OTOH, if it has indeed vanished entirely, then maybe we could argue that there can't be any users and therefore it's okay if the driver stops working in F21. Going forward, if the simpledrm stuff ever starts being fully functional, then it should provide a working, if rather crappy, way to get fixed-resolution graphics running on any new-enough system. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:54:22AM -0800, Andrew Lutomirski wrote: On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett mj...@srcf.ucam.org wrote: It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. OTOH, if it has indeed vanished entirely, then maybe we could argue that there can't be any users and therefore it's okay if the driver stops working in F21. People are using -vesa right now, not uvesafb. Going forward, if the simpledrm stuff ever starts being fully functional, then it should provide a working, if rather crappy, way to get fixed-resolution graphics running on any new-enough system. Non-EFI systems are still going to need some mechanism for calling out to userspace for setting a mode. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
