1142239 - Content sandboxing blocks Nvidia shader cache

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Trevor Rowbotham [:rowbot]]

This probably isn't a super huge deal as stuff is still drawn as it should be, but I figured I would report it anyways.  This may have an adverse affect on power consumption for users with an Nvidia GPU.

STR:
1) Set the pref security.sandbox.content.level to 1
2) Set the pref security.sandbox.windows.log to true
3) Restart the browser
4) Open the browser console
5) Watch a YouTube video using the HTML5 player

Browser console shows lines like the following:

Process Sandbox BLOCKED: NtCreateFile for : \??\C:\Users\Trevor\AppData\Local\Temp\NVIDIA Corporation\NV_Cache\d4db2017b9eb34d5785fd0119370c437_fce8395c8fd8a849_8e912777872ba4e3_4_0.toc

Taken from [1]:
> In today's 337.88 WHQL drivers we've introduced a new NVIDIA Control Panel
> feature called "Shader Cache", which saves compiled shaders to a cache on
> your hard drive. Following the compilation and saving of the shader, the
> shader can simply be recalled from the hard disk the next time it is
> required, potentially reducing load times and CPU usage to optimize and
> improve your experience.
> 
> By default the Shader Cache is enabled for all games, and saves up to 256MB
> of compiled shaders in %USERPROFILE%\AppData\Local\Temp\NVIDIA
> Corporation\NV_Cache. This location can be changed by moving your entire
> Temp folder using Windows Control Panel > System > System Properties >
> Advanced > Environmental Variables > Temp, or by using a Junction Point to
> relocate the NV_Cache folder. To change the use state of Shader Cache on a
> per-game basis simply locate the option in the NVIDIA Control Panel, as
> shown below.

[1] http://www.geforce.com/whats-new/articles/nvidia-geforce-337-88-whql-watch-dog-drivers

Comment 1

[Bob Owen (:bobowen)]

Thanks for this, it's really useful.

It's interesting that they state that they are using the environment variable, because we set up a low integrity temp directory that this should be using.
Something is clearly going wrong with that somewhere.

Once, I finish the current thing I'm working on I've got a couple of other things to look at, so I'll ni to make sure I don't forget this.

Comment 2

[Trevor Rowbotham [:rowbot]]

The browser console also showed the following blocked actions:

Process Sandbox BLOCKED: NtOpenKeyEx for : SOFTWARE
Process Sandbox BLOCKED: NtCreateKey for : Software\Microsoft\Direct3D\MostRecentApplication
Process Sandbox BLOCKED: NtCreateKey for : MostRecentApplication

I'm not sure if these were actions Firefox was trying to perform or the Nvidia driver or if they are even related to this bug.

Just so you know, the shader cache is broken regardless of the Windows UAC setting since the last few bugs of mine that you have looked at were a result of me having UAC turned off. (I'm giving UAC another try just for you!)

Comment 3

[Bob Owen (:bobowen)]

Looks like it is picking up the TEMP environment variable before we lower the token and change it to the low integrity temp.

Hopefully, soon we'll be able to start the process at low integrity and set up the temp directory before this happens.

I notice that the Chrome gpu process is currently blocking access to these files as well.

Comment 4

[Bob Owen (:bobowen)]

This should be fixed when I fix bug 1149483.

Comment 5

[Trevor Rowbotham [:rowbot]]

It looks like bug 1149483 did fix this as I am no longer seeing messages about these files being blocked.

Comment 6

[Bob Owen (:bobowen)]

(In reply to Trevor Rowbotham from comment #5)
> It looks like bug 1149483 did fix this as I am no longer seeing messages
> about these files being blocked.

Thanks for testing this.

They are now picking up the low integrity temp as it is set right near the start of the process.
I'm not sure if having a per-process cache like this will cause any issues.
The temp directory should get cleaned up on a clean shutdown.

I still need to work on cleaning up old dirs caused by crashes / kills.