Maybe it’s time to talk about a new Linux Display Driver Model • Hacker News Board

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

#21

Post by tbirdz » Sat, Sep 05, 2015, 8:14 PM UTC

0x0 wrote: post #18

sliverstorm wrote: post #10

Earlier quoted context omitted.

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) - "w…

> 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.

gdb, when using it to attach to an already running process.

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

#22

Post by jbuzbee » Sat, Sep 05, 2015, 8:15 PM UTC

Animats wrote: post #16

Be grateful that graphics cards work on Linux at all. For over a decade, they barely did.

Depends on what you mean. I've been running Linux for 20+ years and have never had a graphics card that I couldn't get to work. If you're talking about acceleration, there have obviously been issues getting manufacturer support, but as a non-gamer, that mattered little to me.

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

#23

Post by 0x0 » Sat, Sep 05, 2015, 8:16 PM UTC

tbirdz wrote: post #21

0x0 wrote: post #18

Earlier quoted context omitted.

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) - "w…

> 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. gdb, when using it to attach to an already running process.

Not exactly, GDB would be accessing memory that is still allocated. I think the OP was referring to accessing memory contents from deallocated regions. Also we're talking GPU memory here, for the most part. :)

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

#24

Post by doesnotmatter » Sat, Sep 05, 2015, 8:27 PM UTC

Yea, that's cute, except that DRM can handle pretty much all of it. You can split hairs and complain about GPU scheduling which is inherently rather difficult because scheduling at the command queue level is problem very much alike the halting problem. The real issue isn't that we don't have the pieces we need but rather that we can't get all the players to agree on using the same ones. On Windows you have one entity (Microsoft) that can post WLK and unless you pass it you won't be certified and on GNU/Linux "a working driver" can be anything from "not catching on fire on boot" through "actually brings up display" to "oh, hey a textured triangle!". And I get it, everyone is frustrated because ultimately displaying a bunch of pixels, seems trivial, that is, until you mix in politics. You have NVIDIA, AMD, Intel and the community at large pulling all in different directions. With GNU/Linux graphics support having marginal effect on the bottom line there's little incentive to deal with it. And you'd still miss a controlling entity that could validate that "works on Linux" means anything but "compiles with some random kernel release".

Everyone who thinks that writing great graphics drivers can be a spare time activity is delusional. The fact that we have Android with Gralloc (which in comparison to DRM is, well, a joke), Ubuntu with Mir, others trying out Wayland and folks still stuck on X11 makes this all so much more complicated than it needs to be (and SteamOS is rather terrible in this regard too, which is a shame because Valve is trying to do the right thing with Vulkan but SteamOS is just not a well put together distro, at least right now). It's just not a driver model problem, it's the politics of it all. Outside of Google adopting DRM instead of Gralloc (or Gralloc getting all of the features on DRM and effectively becoming DRM and replacing it on the desktop) there's probably little chance of unifying all the drivers under one coherent umbrella.

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

#25

Post by mfisher87 » Sat, Sep 05, 2015, 8:52 PM UTC

jbuzbee wrote: post #22

Animats wrote: post #16

Be grateful that graphics cards work on Linux at all. For over a decade, they barely did.

Depends on what you mean. I've been running Linux for 20+ years and have never had a graphics card that I couldn't get to work. If you're talking about acceleration, there have obviously been issues getting manufacturer support, but as a non-gamer, that mattered little to me.

Haven't been using linux as long as you, more like 10-15 years, but I've noticed during that time that the effort required to get a graphics device working has shrunk significantly (and I don't attribute that to an increase in my knowledge).

I definitely use linux primarily for other stuff these days, though, so it's not often I'm setting up a new graphics card with linux anymore.

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

#26

Post by tedunangst » Sat, Sep 05, 2015, 9:05 PM UTC

doesnotmatter wrote: post #24

Yea, that's cute, except that DRM can handle pretty much all of it. You can split hairs and complain about GPU scheduling which is inherently rather difficult because scheduling at the command queue level is problem very much alike the halting problem. The real issue isn't that we don't have the pieces we need but rather that we can't get all the players to agree on using the same ones. On Windows you have one entity…

Calling it a political problem and not a technical problem doesn't make it less of a problem. Nor does dismissing it as "cute" offer much in the way of a solution.

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

#27

Post by Someone » Sat, Sep 05, 2015, 9:30 PM UTC

geofft wrote: post #19

rbanffy wrote: post #6

Earlier quoted context omitted.

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.…

"On desktop Linux, it's obvious that, say, a web browser and a PDF viewer should be different applications"

Not completely obvious. The web browser could use the PDF viewer to render PDF and/or the PDF viewer could use the web browser to run JavaScript embedded in a PDF file (http://www.adobe.com/devnet/acrobat/javascript.html). Both examples are similar to your find|grep example.

Yes, that typically would be done by reusing libraries, not by starting processes, but modern browsers run a separate process per tab and some run flash in a separate process. Running a PDF viewer in a separate process would be a logical extension.

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

#28

Post by [deleted] » Sat, Sep 05, 2015, 9:31 PM UTC

thrownaway2424 wrote: post #3

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.

[deleted]

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

#29

Post by timthelion » Sat, Sep 05, 2015, 9:32 PM UTC

geofft wrote: post #19

rbanffy wrote: post #6

Earlier quoted context omitted.

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.…

Perhaps you would be interested in my project, subuser.org

Unfortunately, it does absolutely NOTHING with regard to OpenGL isolation :( (That is if you give programs permission to talk to the graphics card, which is denied by default...)

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

#30

Post by Someone » Sat, Sep 05, 2015, 9:43 PM UTC

0x0 wrote: post #18

sliverstorm wrote: post #10

Earlier quoted context omitted.

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) - "w…

Reminds me of GO.COM (http://peetm.com/blog/?p=55) That is/was an example.

GO.COM contained no program bytes at all – it was entirely empty. However, because GO.COM was empty, but still a valid program file as far as CP/M was concerned (it had a directory entry and file-name ending with .com), the CP/M loader, the part of the OS whose job it is to pull programs off disk and slap them into the TPA, would still load it!

So, how does this help? Well, using the scenario above:

the user exited WordStar the user ran DIR (or whatever else they needed) and at some future point would be ready to re-run Wordstar the user now ‘loaded’ and ran GO.COM the loader would load zero bytes of the GO.COM program off disk into the TPA – starting at address 0100h – and then jump to 0100h – to run the program it just loaded [GO.COM]!

result – it simply re-ran whatever was in the TPA when the user last exited to DOS – instantly"

It also wasn't unusual to try and recover data from memory after a program crashed by launching a small program that dumped memory to disk. 100% reliable? No, but it was the best one sometimes had.