Nvidia Blames Apple For Bug That Exposes Browsing In Chrome's Incognito (venturebeat.com)

An anonymous reader points out this story at VentureBeat about a bug in Chrome's incognito mode that might be a cause for concern for some Apple users. From the story: "If you use Google Chrome's incognito mode to hide what you browse (ahem, porn), this might pique your interest. University of Toronto engineering student Evan Andersen discovered a bug that affects Nvidia graphics cards, exposing content that you thought would be for your eyes only. And because this only happens on Macs, Nvidia is pointing the finger at Apple."

Comments

It's your own fault Apple

[Anonymous Coward]

You insist on having your own slow ass OpenGL implementation for our cards, I guess you fucked up on security too.

Re:It's your own fault Apple

[Anonymous Coward]

You insist on having your own slow ass OpenGL implementation for our cards, I guess you fucked up on security too.

Patches from your proprietary GL implementation donated to the OpenGL Open Source project welcome, nVidia... don't bitch that it's slow when you're able to fix the slow yourselves.

You don't understand. *Apple* insists on having their own OpenGL implementation for GPUs they use (so they have identical GL api support on intel, amd and nvidia). They don't use Nvidia proprietary driver code, nor Open Source code, and since they don't care about performance (because of metal), their implementation is slow-ass...

Now get off my lawn ;^)

Except it's not.

[Anonymous Coward]

This isn't just on Apple's OS. While I have nothing like Mr. Andersen's writeup to prove it, I've seen this kind of bug happen on Windows.

Simple explanation

[mcrbids]

So, your program allocates some memory. Should it initialize the memory to make sure it's all a bunch of zeros? Apparently, Nvidia doesn't think so.

So, a program running on your OS requests some memory. Should the OS initialize the memory before handing it to the application? Apparently, Apple doesn't think so.

Either answer is right.

Re:Simple explanation

[dgatwood]

Not really. An application will typically allocate and release memory all the time, being forced to clear it every time is massive overkill and a performance problem. The driver exposes the GPU memory, the OS allocates it to applications just like with RAM. It's the only one that knows when memory switches application context and must be cleared. So there's really only one sane solution.

The usual solution is basically:

• Whenever you add a new page into an application's address space, you map a zero-filled page as copy-on-write. If the page never gets touched, it is zero-filled, and you take the performance hit only when it ceases to be all zeroes.
• Small allocations are allocated using a pool allocator backed by those pages.

This works well as long as the CPU is in charge, ensuring that any dirty data must have originated in some other part of the app (by reusing a pool region). Where it starts to get hairy is when you have a GPU that has access to all of RAM and uses a separate page table with separate COW flags, etc.

I'm not certain what went wrong in this particular case. However, I do remember a really annoying change in about 10.6 or 10.7 where Apple stopped using a vertical blanking interrupt to control various aspects of the GPU's operation and maybe some other parts of the OS. This improved battery life, IIRC, but the result is that you'll often see the GPU draw a frame of video before the previous contents of VRAM have gotten wiped. I would not be at all surprised if that was what happened here.

As for whose responsibility it is to clear the memory, my gut says that if Chrome wants to guarantee that its video buffers are cleared, Chrome is responsible for doing it. Otherwise, it should assume that VRAM is a shared resource, and anything it puts in VRAM can potentially be accessed by any other app at any time for any reason. With that said, I'm open to other opinions on the matter.

Re:Chrome?

[Anonymous Coward]

No, his reason is that sweet sweet +5 insightful. We don't need your facts around here.

This, this, this!

[tlambert]

Chrome advertises its Incognito mode as leaving no traces behind. Therefore, it should be responsible for wiping its framebuffer, just as it clears caches, cookies and history. It's like writing a file shredder that doesn't actually overwrite files, then blaming the OS and hard drive manufacturer for the oversight.

This, this, this!

If it's incognito, it should not trust anyone else to ensure the privacy of the user's data, not even the OS. We already know that it's possible to use CPU cache bugs as a covert channel to snoop on other processes running on your computer; if the application claims to maintain security, it needs to zero the memory itself.

As an aside, a GPU is a better machine for zeroing pages than the main CPU, and won't pipeline stall or time stall the main CPU by doing it, and GPUs are traditionally really good at manipulating large amounts of memory. So one has to wonder: why doesn't nVidia expose a primitive that Chrome can then use to zero the pages of a frame buffer, before or after it is used?

Re: Blame Chrome

[guruevi]

There are also some limitations to what a program promises vs what it can do. File shredding is an optimal example: modern SSD do not even write to the same physical location every time you write to the same file. Battery backed controllers fool the OS in thinking a certain action was completed while it really wasn't committed to disk yet. If you pull a disk between the shredding event and the cache flush, you could easily read things. Heck, if your magnetic drive says a portion of it's drive are "bad blocks" the data on those blocks doesn't get overwritten, SSD's have cells that can physically go "read-only", with the right tools you can read the data in the "bad blocks" or "read only" cells.