Live data from Hacker News

Maybe it’s time to talk about a new Linux Display Driver Model

yosoygames.com.ar

11–20 of 69 posts

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#11
post #7
post #5

Earlier quoted context omitted.

This is extra fun considering WebGL.

WebGL implementations zero out newly allocated buffers for exactly that reason. https://www.khronos.org/registry/webgl/specs/latest/1.0/#4

How long until we get a heartbleed-like attack where some software overruns its GPU buffer into a webgl buffer?

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#12
post #7

Earlier quoted context omitted.

WebGL implementations zero out newly allocated buffers for exactly that reason. https://www.khronos.org/registry/webgl/specs/latest/1.0/#4

How long until we get a heartbleed-like attack where some software overruns its GPU buffer into a webgl buffer?

FWIW I've been running with WebGL disabled because of similar concerns.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#18
post #6

Earlier quoted context omitted.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

Knowing nothing about the issue, I speculate many programs have come to depend on the behavior. Similar to antique bugs in x86 that were baked in to the architecture when programmers had to work with them on the 286 & 386. After that they couldn't be fixed because programs depended on the presence of the bug.

I'm having a very hard time imagining there exists even a single program out there that depends on being able to read the memory contents of a program that ran before itself.

I bet it comes down to driver developers never even thinking that this could be a security issue before people came up with the concept of running unauthenticated 3d accelerated software (i.e. javascript+webgl from the network in a browser) - "what do you mean security, the user could just have taken a screenshot at any time. why should we waste precious FPS clearing buffers when the program will fill in its own textures before drawing anything".

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#19
post #6

The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

The Yama patchset has been in mainline for the last few years, and disallows non-root processes from reading each others' memory (except for direct children).

The trouble is that it's a sort of retrofitted check. It works surprisingly well, but being added to a 20+-year-old OS and a 40+-year-old design, it can't guarantee being correct. The traditional, historic process boundary on UNIX has been user accounts / UIDs. Desktop Linux needs to figure out a way to do what Android does, and run every application with a separate UID, including the ability to have private files that are unreadable to other applications.

The challenge is defining "application". Android, being a greenfield platform, could define the interaction between applications. On desktop Linux, it's obvious that, say, a web browser and a PDF viewer should be different applications. The two processes in a "find | grep" shell pipeline probably should count as the same application. In between, it's pretty blurry, because we've had 40 years to develop patterns that don't account for this isolation ever happening.

Post reply on HN