If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Working Out "Serious Security Flaws" In DRM Drivers

Phoronix: Working Out "Serious Security Flaws" In DRM Drivers

While many are still busy working through fallout of the OpenSSL Heartbleed bug within organizations, on a separate but security related note, kernel developers specializing in the Direct Rendering Manager (DRM) graphics drivers are working to beef up their own driver security...

Wayland doesn't use DRM right?
I mean, ofc it's going to have it's own set of security flaws among other bugs, but this giant mess that is "X.org security" won't affect those of us switching over when it's ready, right?

Wailand uses DRM as well, DRI is the one specific to X. And I remember this security issues being also mentioned at the latest X.org conf, and they were supposed to be fixed, among other, by the switch to DRI3.

Wayland doesn't use DRM right?
I mean, ofc it's going to have it's own set of security flaws among other bugs, but this giant mess that is "X.org security" won't affect those of us switching over when it's ready, right?

The whole DRM Master thing will affect Wayland, AFAIK. That being said, the split with Render Nodes may help that a little since its delegation of responsibilities. Wayland, however, is not affected by the mess of security issues that may be lurking in the 20+ yr old codebase that is Xorg. DRI3 + Present may have fixed a couple of these issues since now buffers are passed through DMA-BUF via file descriptors of a socket-- which is supposed to be more secure than however DRI2 handled it.

I remember in the good old days, flaws in the DRM drivers like not clearing graphics memory and having images appear on the screen at untimely moments. For example while mode switching, or shutting down/restarting that goatse pr0n image might appear

I remember in the good old days, flaws in the DRM drivers like not clearing graphics memory and having images appear on the screen at untimely moments. For example while mode switching, or shutting down/restarting that goatse pr0n image might appear

Wailand uses DRM as well, DRI is the one specific to X. And I remember this security issues being also mentioned at the latest X.org conf, and they were supposed to be fixed, among other, by the switch to DRI3.

a couple points to make before people get too alarmed (or at least to put this in context):

1) this is strictly about information leaks. Not root escalation, or anything like that... I think drm and the open src drivers are at quite likely better than the closed src drivers in that regard.

2) render-nodes and dri3 do address the guessability of other drm-master's buffers (which only effects shared buffers, ie. ones with flink names)

3) the remaining point that Thomas is trying to make is that, some hardware there may not be isolation between different processes gpu buffers, ie. $evil_userspace could conceivable craft gpu commands to read out all your VRAM/etc. Of the top of my head, I believe intel/radeon/nouveau all support per-process pagetables to stop that, but not sure if it is on all hw generations/etc.

If you are really paranoid, you probably want to consider not using a gpu at all (on windows or linux, opensrc drivers or (especially) closed src drivers).