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

Re:Maybe it’s time to talk about a new Linux Display Driver ... by sliverstorm on Saturday September 05, 2015 @03:12PM (#10175747)

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.

[ Parent | on HN ]

Re:Maybe it’s time to talk about a new Linux Display Driver ... by 0x0 on Saturday September 05, 2015 @04:06PM (#10175905)

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

[ Parent | on HN ]

Re:Maybe it’s time to talk about a new Linux Display Driver ... by Someone on Saturday September 05, 2015 @05:43PM (#10176141)

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.

[ Parent | on HN ]

Re:Maybe it’s time to talk about a new Linux Display Driver ... by rbanffy on Sunday September 06, 2015 @01:33PM (#10178321)

The best thing about go.com (I called it x.com) is that, if you don't have one on your disk, you can simply do

    SAVE 0 X.COM

and it'll be there for you.

[ Parent | on HN ]

Re:Maybe it’s time to talk about a new Linux Display Driver ... by tbirdz on Saturday September 05, 2015 @04:14PM (#10175929)

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

[ Parent | on HN ]

Re:Maybe it’s time to talk about a new Linux Display Driver ... by 0x0 on Saturday September 05, 2015 @04:16PM (#10175935)

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

[ Parent | on HN ]