Hacker News Reader

Comment by charliehorse55 | Hacker News Reader

Yeah, I remember reading that when it was first posted. Glad to see other people are aware, but it's disappointing nothing has been done.

The fix is pretty simple, the GPU manufacturer just needs to update their driver to zero the VRAM like an OS would with RAM.

View on HN

Or the window manager should zero things out? It seems more consistent for the OS to be responsible for this then say the driver which also does things like supporting OpenGL and GPGPU usecases.

You can generally allocated GPU buffers without the window manager. So to be effective this would have to be in the kernel driver. Opengl/GPGPU is generally done in the user space driver so it'd still be separate.

When graphics card vendors want to protect their competitive edge and not do OS integration beyond dropping horrible and opaque binary blobs every now and then, they'll also have to mop up the security issues such as this on their own.

Technically this should be a OS responsibility, but practically the vendors have made that all but impossible.

> The fix is pretty simple, the GPU manufacturer just needs to update their driver to zero the VRAM

You seem to be using OSX (judging by the screenshots).

You should be aware that OSX's GPU drivers are written by Apple (or at least they act as the gatekeeper). You need to send the bug report to them. And perhaps update the title of your post to "Apple breaks..."

I've seen this exact same behavior on OSX with an Intel GPU.

As mentioned elsewhere in this post, e.g. Windows WDDM drivers require memory to be zeroed out.

Are device drivers ever updated, much less for security issues?

Seems like an obvious way to increase the take, in any event: "Chip X has a security flaw. Chip Y does not. Buy chip Y now or Evil People will own-zor all your cash-zors."

People who often play 3D games always update their graphics drivers :)

> Are device drivers ever updated, much less for security issues?

Yep, all the time. http://i.imgur.com/8k3ffLa.png

Since we're talking about GPUs... search the NVIDIA archive [1], and look for the WHQL drivers:

    Version: 359.00 - Release Date: Thu Nov 19, 2015
    Version: 358.91 - Release Date: Mon Nov 09, 2015
    Version: 358.87 - Release Date: Wed Nov 04, 2015
    Version: 358.50 - Release Date: Wed Oct 07, 2015

[1] http://www.nvidia.com/drivers/beta

So what about the BSODs that device drivers cause? Are those not device driver issues, but OS issues, or are they unfixable?

They could be any of those.

In a sense, BSODs aren't anything special -- all a BSOD means is that some code running in kernel mode has crashed or raised some exception that went unhandled. The same thing, when it happens in a user-mode program, gets you the error dialog box 'Program has stopped working'.

So the causes of BSODs and user application crashes are the same. The reason Windows has BSODs is that it's dangerous to keep the system going when something in kernel mode crashes. Things running in kernel mode have access to everything (think - all memory) and are deemed important enough to the operation of the whole system that a crash in one of those is a significant event that's worthy of special logging and rebooting. You can't guarantee, for example, that a display driver crash hasn't corrupted other parts of memory, cuasing potential for data loss if the system were to continue operating.

So, back to the original point. Device-driver BSODs from the big vendors are probably rare enough in general that you should suspect a hardware problem or glitch if you suddenly see one out of the blue. Graphics drivers, given their complexity, are a bit more prone to crashing though. Also, things running on the system can interact and cause the driver to crash.

Windows has lots of infrastructure in place for making sure device drivers behave safely. There's also good facilities for figuring out exactly what caused a BSOD beyond the usually cryptic-looking error code you see on the screen.

Resplendence WhoCrashed is handy: http://www.resplendence.com/whocrashed

Though if you really want to dig deep, the tools with the Windows SDK (particularly WinDbg) can let you achieve the same thing; they are developer tools though, so targeted more to that audience.

EDIT: Just to add in answer to your original comment, big-vendor graphics drivers are VERY often updated. I'd bet they're the most often updated drivers on a system. There are myriad reasons for this, both technical and competitive. That doesn't mean that long-standing problems are necessarily fixed, but both AMD and Nvidia have very regular releases with fixes and performance improvements.

Along a similar line, in my own experience, since around Windows 2000 (not ME) it's extremely rare to see a BSOD that isn't related to either bad hardware or drivers, more often than not hardware related to a driver than the driver itself.

Another subtlety is that the term 'driver' on Windows tends to be used for any loadable module that runs in kernel mode. So a driver often isn't actually related to running a particular piece of hardware. Rather, it's a piece of software that needs kernel-mode access to the system.

Two examples that demonstrate this point well:

- There are various tools out there that you can use to perform a live memory capture on a Windows system; not just doing a memory dump of a single process, but doing a live memory dump of the whole system without having to halt or reboot. I've used one of these and it works by loading a 'driver' component when it is run that does the memory capture from kernel-mode (it requires Admin elevation to run, obviously).

(For examples, see: http://www.forensicswiki.org/wiki/Tools:Memory_Imaging

I don't remember if it was one off this list that I tried though).

Another example: A friend of mine had a system that would inexplicably BSOD if he left it running for a long while, unattended (especially overnight). We initially suspected perhaps a heating issue (it was a small Intel NUC). After setting up for full memory dumps and then analyzing them after a BSOD occurred using WinDbg, we actually found out that the BSOD was being caused by a kernel-mode component of the anti-virus suite that he had installed -- I think at the time it was BitDefender, but not sure. When he consulted the AV vendor support website, I believe it turned out to be a known issue with a fix.

On my own systems, by far the largest cause of BSODs (of the few that I've seen over the last couple of years) has been RAM going bad. These typically manifest as BSODs out of the blue that seem to come from different modules each time they happen, or they come from a module deep in the system that 'shouldn't' have crashes. My personal rule is, if I see one, be vigilant. If I see another one, reboot and run MemTest86.

In practice, other than the Windows Kernel, the only things running in kernel space tend to be drivers, a/v software and malicious code.

Reply on news.ycombinator.com