* [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY @ 2016-08-04 8:06 David Herrmann 2016-08-04 8:06 ` [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN David Herrmann 2016-08-04 8:13 ` [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY Chris Wilson 0 siblings, 2 replies; 10+ messages in thread From: David Herrmann @ 2016-08-04 8:06 UTC (permalink / raw) To: dri-devel; +Cc: Daniel Vetter Lets move forward and hide the remaining DRI1 drivers behind a config option, so we have a central place to disable them all. Furthermore, we can provide a clear warning to anyone enabling them. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> --- drivers/gpu/drm/Kconfig | 135 ++++++++++++++++++++++++++++-------------------- 1 file changed, 78 insertions(+), 57 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index fc35731..d8f6203 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -108,24 +108,8 @@ config DRM_KMS_CMA_HELPER source "drivers/gpu/drm/i2c/Kconfig" -config DRM_TDFX - tristate "3dfx Banshee/Voodoo3+" - depends on DRM && PCI - help - Choose this option if you have a 3dfx Banshee or Voodoo3 (or later), - graphics card. If M is selected, the module will be called tdfx. - source "drivers/gpu/drm/arm/Kconfig" -config DRM_R128 - tristate "ATI Rage 128" - depends on DRM && PCI - select FW_LOADER - help - Choose this option if you have an ATI Rage 128 graphics card. If M - is selected, the module will be called r128. AGP support for - this card is strongly suggested (unless you have a PCI version). - config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI @@ -177,49 +161,8 @@ source "drivers/gpu/drm/amd/acp/Kconfig" source "drivers/gpu/drm/nouveau/Kconfig" -config DRM_I810 - tristate "Intel I810" - # !PREEMPT because of missing ioctl locking - depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN) - help - Choose this option if you have an Intel I810 graphics card. If M is - selected, the module will be called i810. AGP support is required - for this driver to work. - source "drivers/gpu/drm/i915/Kconfig" -config DRM_MGA - tristate "Matrox g200/g400" - depends on DRM && PCI - select FW_LOADER - help - Choose this option if you have a Matrox G200, G400 or G450 graphics - card. If M is selected, the module will be called mga. AGP - support is required for this driver to work. - -config DRM_SIS - tristate "SiS video cards" - depends on DRM && AGP - depends on FB_SIS || FB_SIS=n - help - Choose this option if you have a SiS 630 or compatible video - chipset. If M is selected the module will be called sis. AGP - support is required for this driver to work. - -config DRM_VIA - tristate "Via unichrome video cards" - depends on DRM && PCI - help - Choose this option if you have a Via unichrome or compatible video - chipset. If M is selected the module will be called via. - -config DRM_SAVAGE - tristate "Savage video cards" - depends on DRM && PCI - help - Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister - chipset. If M is selected the module will be called savage. - config DRM_VGEM tristate "Virtual GEM provider" depends on DRM @@ -290,3 +233,81 @@ source "drivers/gpu/drm/arc/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" source "drivers/gpu/drm/mediatek/Kconfig" + +# Keep legacy drivers last + +menuconfig DRM_LEGACY + bool "Enable legacy drivers (DANGEROUS)" + depends on DRM + help + Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous + APIs to user-space, which can be used to circumvent access + restrictions and other security measures. For backwards compatibility + those drivers are still available, but their use is highly + inadvisable and might harm your system. + + You are recommended to use the safe modeset-only drivers instead, and + perform 3D emulation in user-space. + + Unless you have strong reasons to go rogue, say "N". + +if DRM_LEGACY + +config DRM_TDFX + tristate "3dfx Banshee/Voodoo3+" + depends on DRM && PCI + help + Choose this option if you have a 3dfx Banshee or Voodoo3 (or later), + graphics card. If M is selected, the module will be called tdfx. + +config DRM_R128 + tristate "ATI Rage 128" + depends on DRM && PCI + select FW_LOADER + help + Choose this option if you have an ATI Rage 128 graphics card. If M + is selected, the module will be called r128. AGP support for + this card is strongly suggested (unless you have a PCI version). + +config DRM_I810 + tristate "Intel I810" + # !PREEMPT because of missing ioctl locking + depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN) + help + Choose this option if you have an Intel I810 graphics card. If M is + selected, the module will be called i810. AGP support is required + for this driver to work. + +config DRM_MGA + tristate "Matrox g200/g400" + depends on DRM && PCI + select FW_LOADER + help + Choose this option if you have a Matrox G200, G400 or G450 graphics + card. If M is selected, the module will be called mga. AGP + support is required for this driver to work. + +config DRM_SIS + tristate "SiS video cards" + depends on DRM && AGP + depends on FB_SIS || FB_SIS=n + help + Choose this option if you have a SiS 630 or compatible video + chipset. If M is selected the module will be called sis. AGP + support is required for this driver to work. + +config DRM_VIA + tristate "Via unichrome video cards" + depends on DRM && PCI + help + Choose this option if you have a Via unichrome or compatible video + chipset. If M is selected the module will be called via. + +config DRM_SAVAGE + tristate "Savage video cards" + depends on DRM && PCI + help + Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister + chipset. If M is selected the module will be called savage. + +endif # DRM_LEGACY -- 2.9.2 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-04 8:06 [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY David Herrmann @ 2016-08-04 8:06 ` David Herrmann 2016-08-04 8:15 ` Chris Wilson 2016-08-26 2:18 ` Dave Airlie 2016-08-04 8:13 ` [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY Chris Wilson 1 sibling, 2 replies; 10+ messages in thread From: David Herrmann @ 2016-08-04 8:06 UTC (permalink / raw) To: dri-devel; +Cc: Daniel Vetter The legacy DRI1 drivers expose highly broken interfaces to user-space. No modern system should enable them, or you will effectively allow user-space to circumvent most of your kernel security measures. The DRI1 kernel APIs are simply broken. User-space can always use vesafb/efifb/simplefb and friends to get working graphics. Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to be still used (really?), we can easily revert this and figure out a way to move them out of sight (e.g., moving all DRI1 drivers to drivers/gpu/dri1/). Signed-off-by: David Herrmann <dh.herrmann@gmail.com> --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d8f6203..48d9223 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -239,6 +239,7 @@ source "drivers/gpu/drm/mediatek/Kconfig" menuconfig DRM_LEGACY bool "Enable legacy drivers (DANGEROUS)" depends on DRM + depends on BROKEN help Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous APIs to user-space, which can be used to circumvent access -- 2.9.2 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-04 8:06 ` [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN David Herrmann @ 2016-08-04 8:15 ` Chris Wilson 2016-08-25 11:14 ` Daniel Vetter 2016-08-26 2:18 ` Dave Airlie 1 sibling, 1 reply; 10+ messages in thread From: Chris Wilson @ 2016-08-04 8:15 UTC (permalink / raw) To: David Herrmann; +Cc: Daniel Vetter, dri-devel On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote: > The legacy DRI1 drivers expose highly broken interfaces to user-space. No > modern system should enable them, or you will effectively allow user-space > to circumvent most of your kernel security measures. The DRI1 kernel APIs > are simply broken. > > User-space can always use vesafb/efifb/simplefb and friends to get working > graphics. > > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to > be still used (really?), we can easily revert this and figure out a way to > move them out of sight (e.g., moving all DRI1 drivers to > drivers/gpu/dri1/). > > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> I'd rather have a couple of distro devs check if they are still using any of these, and would value their a-b/r-b. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-04 8:15 ` Chris Wilson @ 2016-08-25 11:14 ` Daniel Vetter 2016-08-25 15:04 ` Emil Velikov 0 siblings, 1 reply; 10+ messages in thread From: Daniel Vetter @ 2016-08-25 11:14 UTC (permalink / raw) To: Chris Wilson, David Herrmann, dri-devel, Daniel Vetter, Dave Airlie On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote: > On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote: > > The legacy DRI1 drivers expose highly broken interfaces to user-space. No > > modern system should enable them, or you will effectively allow user-space > > to circumvent most of your kernel security measures. The DRI1 kernel APIs > > are simply broken. > > > > User-space can always use vesafb/efifb/simplefb and friends to get working > > graphics. > > > > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to > > be still used (really?), we can easily revert this and figure out a way to > > move them out of sight (e.g., moving all DRI1 drivers to > > drivers/gpu/dri1/). > > > > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> > > Acked-by: Chris Wilson <chris@chris-wilson.co.uk> > > I'd rather have a couple of distro devs check if they are still using > any of these, and would value their a-b/r-b. Mesa stopped shipping dri1 drivers years ago, and neither Fedora and Debian here have that old version packaged (it should keep working since the dri loader is an ABI). I don't think anyone needs this, and if I'm wrong we'll hear about it ;-) Both applied to drm-misc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-25 11:14 ` Daniel Vetter @ 2016-08-25 15:04 ` Emil Velikov 2016-08-25 15:13 ` Alex Deucher 0 siblings, 1 reply; 10+ messages in thread From: Emil Velikov @ 2016-08-25 15:04 UTC (permalink / raw) To: Daniel Vetter, ConnorBehan; +Cc: Daniel Vetter, ML dri-devel On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote: >> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote: >> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No >> > modern system should enable them, or you will effectively allow user-space >> > to circumvent most of your kernel security measures. The DRI1 kernel APIs >> > are simply broken. >> > >> > User-space can always use vesafb/efifb/simplefb and friends to get working >> > graphics. >> > >> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to >> > be still used (really?), we can easily revert this and figure out a way to >> > move them out of sight (e.g., moving all DRI1 drivers to >> > drivers/gpu/dri1/). >> > >> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> >> >> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> >> >> I'd rather have a couple of distro devs check if they are still using >> any of these, and would value their a-b/r-b. > > Mesa stopped shipping dri1 drivers years ago, and neither Fedora and > Debian here have that old version packaged (it should keep working since > the dri loader is an ABI). I don't think anyone needs this, and if I'm > wrong we'll hear about it ;-) > Archlinux (which seems to be picking more users) is still shipping dri1 drivers - both mesa and X. No idea for many actually use those and/or for how much longer the packages will be around. IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with plans(?) on getting things KMS aware. Not sure if that was by extending the existing radeon kernel, ddx, mesa driver(s) or otherwise. Connor, can you shed some light ? -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-25 15:04 ` Emil Velikov @ 2016-08-25 15:13 ` Alex Deucher 2016-08-25 16:37 ` Connor Behan 0 siblings, 1 reply; 10+ messages in thread From: Alex Deucher @ 2016-08-25 15:13 UTC (permalink / raw) To: Emil Velikov; +Cc: Daniel Vetter, ML dri-devel, ConnorBehan On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote: > On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote: >>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote: >>> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No >>> > modern system should enable them, or you will effectively allow user-space >>> > to circumvent most of your kernel security measures. The DRI1 kernel APIs >>> > are simply broken. >>> > >>> > User-space can always use vesafb/efifb/simplefb and friends to get working >>> > graphics. >>> > >>> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to >>> > be still used (really?), we can easily revert this and figure out a way to >>> > move them out of sight (e.g., moving all DRI1 drivers to >>> > drivers/gpu/dri1/). >>> > >>> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> >>> >>> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> >>> >>> I'd rather have a couple of distro devs check if they are still using >>> any of these, and would value their a-b/r-b. >> >> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and >> Debian here have that old version packaged (it should keep working since >> the dri loader is an ABI). I don't think anyone needs this, and if I'm >> wrong we'll hear about it ;-) >> > Archlinux (which seems to be picking more users) is still shipping > dri1 drivers - both mesa and X. No idea for many actually use those > and/or for how much longer the packages will be around. > > IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with > plans(?) on getting things KMS aware. Not sure if that was by > extending the existing radeon kernel, ddx, mesa driver(s) or > otherwise. > Connor, can you shed some light ? > r128 is 90% the same as early radeons so it would make sense to add support to radeon. Alex _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-25 15:13 ` Alex Deucher @ 2016-08-25 16:37 ` Connor Behan 2016-08-26 4:52 ` Kevin Brace 0 siblings, 1 reply; 10+ messages in thread From: Connor Behan @ 2016-08-25 16:37 UTC (permalink / raw) To: Alex Deucher, Emil Velikov; +Cc: Daniel Vetter, ML dri-devel, Kevin Brace [-- Attachment #1.1.1: Type: text/plain, Size: 3020 bytes --] On 25/08/16 11:13 AM, Alex Deucher wrote: > On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov > <emil.l.velikov@gmail.com> wrote: >> On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote: >>> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote: >>>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote: >>>>> The legacy DRI1 drivers expose highly broken interfaces to user-space. No >>>>> modern system should enable them, or you will effectively allow user-space >>>>> to circumvent most of your kernel security measures. The DRI1 kernel APIs >>>>> are simply broken. >>>>> >>>>> User-space can always use vesafb/efifb/simplefb and friends to get working >>>>> graphics. >>>>> >>>>> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to >>>>> be still used (really?), we can easily revert this and figure out a way to >>>>> move them out of sight (e.g., moving all DRI1 drivers to >>>>> drivers/gpu/dri1/). >>>>> >>>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> >>>> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> >>>> >>>> I'd rather have a couple of distro devs check if they are still using >>>> any of these, and would value their a-b/r-b. >>> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and >>> Debian here have that old version packaged (it should keep working since >>> the dri loader is an ABI). I don't think anyone needs this, and if I'm >>> wrong we'll hear about it ;-) >>> >> Archlinux (which seems to be picking more users) is still shipping >> dri1 drivers - both mesa and X. No idea for many actually use those >> and/or for how much longer the packages will be around. >> >> IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with >> plans(?) on getting things KMS aware. Not sure if that was by >> extending the existing radeon kernel, ddx, mesa driver(s) or >> otherwise. >> Connor, can you shed some light ? >> > r128 is 90% the same as early radeons so it would make sense to add > support to radeon. > > Alex Ccing Kevin Brace. The drivers were removed from mesa and "you won't have to freeze your kernel or anything" was one of the justifications given at the time for why this wasn't a bad idea. So yes, I have dri1 packages in the Archlinux repos with no plans to drop them. The people who have emailed me about them and filed bugs are probably much less than 1% of the user base but I've never considered that relevant. The point is that hobbyists who want to use old hardware or play with seldomly updated drivers should be able to do this without too many additional hurdles. AFAIK the drivers still work as well as they did in the late 90s. And it's easy for security conscious people to not modprobe them. My -1 would probably mean more if I were still following my initial plans of adding r128 support to the radeon kernel module but at some point while reading documentation I lost motivation. Hopefully this is temporary. [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-25 16:37 ` Connor Behan @ 2016-08-26 4:52 ` Kevin Brace 0 siblings, 0 replies; 10+ messages in thread From: Kevin Brace @ 2016-08-26 4:52 UTC (permalink / raw) To: Connor Behan, dri-devel Hi Connor, > > r128 is 90% the same as early radeons so it would make sense to add > > support to radeon. > > > > Alex > > Ccing Kevin Brace. > > The drivers were removed from mesa and "you won't have to freeze your > kernel or anything" was one of the justifications given at the time for > why this wasn't a bad idea. So yes, I have dri1 packages in the > Archlinux repos with no plans to drop them. The people who have emailed > me about them and filed bugs are probably much less than 1% of the user > base but I've never considered that relevant. The point is that > hobbyists who want to use old hardware or play with seldomly updated > drivers should be able to do this without too many additional hurdles. > > AFAIK the drivers still work as well as they did in the late 90s. And > it's easy for security conscious people to not modprobe them. My -1 > would probably mean more if I were still following my initial plans of > adding r128 support to the radeon kernel module but at some point while > reading documentation I lost motivation. Hopefully this is temporary. > > > I should not make any mockery of people's sincere beliefs, but at this point as a non-corporate graphics stack developer (of course, I have worked only on DDX so far), I am starting to see the perspectives of those who are anti-consumerism a little bit. Every year around Black Friday (For those who are not too familiar with US customs and holidays, Thanksgiving is one of the major holiday here, but more importantly for retailers and computer hardware corporations, Black Friday is really the biggest event of the year where silicon-based products assembled in China as circuit boards moves in huge numbers, hence, they get to keep engineers, marketers, and CEOs employed.) there are people who preach anti-consumerism against the huge Black Friday tide. Of course, based on what I see around the parking lot of Fry's Electronics (a major US based electronics retailer HQed here in San Jose, CA, USA) on Black Friday, I do not think they are winning the conversion war (I am not religious, but it is sort of a pseudo-religion, similar to "some" evangelical Protestant Christians or Mormons who do street evangelism from time to time, but do not appear to convert too many people.), but sometimes when I see the still usable computer hardware being tossed out at the so called "e-waste" site, I always wonder if there is a good way to give second or even third life to the soon to be crushed computer hardware still fairly useful for ordinary (i.e., non-gamer) use. Anyway, I started collecting probably too much abandoned computer hardware, and I have to joking call it "I built a computer parts empire" where I live since I own so much computer equipment, probably more than I really need. I will like to give second and third life to the hardware I have collected over the past 6 years, and ultimately, this is how I ended up working on OpenChrome as a result. Since I am starting to show sympathy towards anti-consumerism people and views (I am still not totally sold on it, but starting to understand where they are coming from.) I sort of have to wonder about the motivations of many of the corporate "paid" OSS developers, especially the device driver developer types. I know security issues do matter, but in some ways, rapid obsolescence thing I am sure comes into play. Corporations like Intel and AMD (and many others involved in OSS) have to keep selling silicon based products to keep their engineers (and marketers and CEOs) employed, and it is not too nice financially to them if people keep clinging onto their dated hardware (like clinging onto a gun and religion as one politician once said privately, but it was supposedly a taboo subject in portions of the country, hence, it became a big story prior to an election) due to some guy like myself or Connor Behan continues to somehow churn out code that makes the dated hardware a little more useful. As a developer of OpenChrome, I am getting into this ad hoc alliance of convenience (That's the way I see it. I hope Connor gets my humor.) with Connor Behan of xf86-video-r128. In fact, it was Connor that CCed me the reply he sent to this mailing list, and this is why I am even writing this post. Like Connor, I will not want to see VIA DRI1 module removed from the Linux kernel for now, but since this is a mere ad hoc alliance of convenience, I am okay with dropping or demoting DRI1 support as long as some other more experienced OSS developers can assist in developing drm-openchrome and EXA acceleration support for DRI2 inside OpenChrome DDX since a lot of the drm-openchrome has been written already. I probably already offended too many people in this post (i.e., anti-consumerism people, religious people, gun owners, people who were offended by the "guns and religon" comment, engineers who work at silicon vendors like Intel, AMD, etc, and maybe even Connor Behan.), I will keep it there. But I am sure some people enjoyed my essay here. Regards, Kevin Brace P.S. I will not be surprised if I am blacklisted at various silicon vendors for showing sympathy towards anti-consumerism. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN 2016-08-04 8:06 ` [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN David Herrmann 2016-08-04 8:15 ` Chris Wilson @ 2016-08-26 2:18 ` Dave Airlie 1 sibling, 0 replies; 10+ messages in thread From: Dave Airlie @ 2016-08-26 2:18 UTC (permalink / raw) To: David Herrmann; +Cc: Daniel Vetter, dri-devel On 4 August 2016 at 18:06, David Herrmann <dh.herrmann@gmail.com> wrote: > The legacy DRI1 drivers expose highly broken interfaces to user-space. No > modern system should enable them, or you will effectively allow user-space > to circumvent most of your kernel security measures. The DRI1 kernel APIs > are simply broken. > > User-space can always use vesafb/efifb/simplefb and friends to get working > graphics. > > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to > be still used (really?), we can easily revert this and figure out a way to > move them out of sight (e.g., moving all DRI1 drivers to > drivers/gpu/dri1/). > > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> So my opinion is that no modern system enables them in practice. You can only load dri1 drivers on dri1 hardware, so you aren't exactly leaving yourself open to root holes here. If you mean the fact that we keep leaving the ioctls answering when dri2 drivers are loaded due to errors, then I hope we've figured all those out by now. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY 2016-08-04 8:06 [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY David Herrmann 2016-08-04 8:06 ` [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN David Herrmann @ 2016-08-04 8:13 ` Chris Wilson 1 sibling, 0 replies; 10+ messages in thread From: Chris Wilson @ 2016-08-04 8:13 UTC (permalink / raw) To: David Herrmann; +Cc: Daniel Vetter, dri-devel On Thu, Aug 04, 2016 at 10:06:56AM +0200, David Herrmann wrote: > Lets move forward and hide the remaining DRI1 drivers behind a config > option, so we have a central place to disable them all. Furthermore, we > can provide a clear warning to anyone enabling them. > > Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Very neatly done. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-08-26 4:52 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-04 8:06 [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY David Herrmann 2016-08-04 8:06 ` [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN David Herrmann 2016-08-04 8:15 ` Chris Wilson 2016-08-25 11:14 ` Daniel Vetter 2016-08-25 15:04 ` Emil Velikov 2016-08-25 15:13 ` Alex Deucher 2016-08-25 16:37 ` Connor Behan 2016-08-26 4:52 ` Kevin Brace 2016-08-26 2:18 ` Dave Airlie 2016-08-04 8:13 ` [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY Chris Wilson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.