Vulkan-docs: Clarify access to other applications' data

[philiptaylor]

https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#fundamentals-errors says:

However, implementations must ensure that incorrect usage by an application [...] does not allow one application to access data belonging to another application.

One reasonable interpretation is that if another application has stored some (possibly sensitive) data in a piece of memory, and then freed that memory, the data no longer belongs to that application, and therefore the implementation can happily let another application access that data.

I assume this isn't the intended meaning, because that seems like a significant security vulnerability that violates the OS's attempts at process isolation. The implementation should be expected to zero any physical memory that was previously owned by an application before making it accessible to another application.

(This matters since it appears some implementations (e.g. NVIDIA on Linux) are currently broken - if an application doesn't correctly initialise an texture then it can contain random pixels from some other unrelated application. I wouldn't be happy if e.g. any random Android app could trivially read the graphic buffers from a banking app that had been previously running.)

The spec should be clarified so that it's not open to interpretation here.

The current text also seems to ignore that there are cases where you _do_ want applications to access each other's data (e.g. gralloc buffers are frequently shared between processes on Android), subject to security policies defined by the platform.

Maybe it should say something more like "... does not allow one application to access data that was written by another application, except where specifically permitted by the operating system's security policies".

[nsf]

Image proof (shows readable garbage from a visited web page not so long time ago):

[NicolBolas]

The implementation should be expected to zero any physical memory that was previously owned by an application before making it accessible to another application.

I don't agree with this at all.

Vulkan exists for the purpose of performance. As such, to force implementations to zero out all memory before giving it to the application is antithetical to performance. As is forcing implementations to zero out memory when you free it.

Process isolation (not being able to read/write memory someone else owns) is one thing. But this level of robustness is something that will impact performance. And Vulkan applications are intended to be running locally on your machine (rather than through a web page like WebGL). So there's already a level of trust that should exist between the user and the application.

At best, there should be some kind of device extension (like OpenGL's robustness support) that the user can turn on if they explicitly want this (specifically, automatically zeroing out freed memory). But otherwise, no.

The security vulnerability is in the application that failed to clear the memory they owned themselves, not in the driver.

Now, I will say this: because you don't have access to swap-chain image memory directly, it's perfectly OK for the implementation to make sure that any data stored in them is either zero or data previously written by that application. And to zero it out after it deallocates such memory.

[philiptaylor]

Vulkan exists for the purpose of performance

I believe it aims for performance within a certain set of constraints, and one constraint nowadays is that the GPU violating the OS's security model is unacceptable.

(I remember hearing that one of the reasons behind Vulkan choosing to drop almost all driver error-checking compared to OpenGL is that modern hardware can provide sufficient safety by itself, protecting the rest of the system from a buggy or malicious application. That argument sounds fine in most cases - but if a particular device can't prevent information leakage vulnerabilities for free, the driver will have to take the performance hit.)

[NicolBolas]

one constraint nowadays is that the GPU violating the OS's security model is unacceptable.

If the OS has a such a security model, then it is the OS's responsibility to _enforce_ it. If the OS wants to ensure that data from one application does not reach another, it has the ability to do so. It owns the GPU, after all, and it can decide to clear out graphics memory when it is deallocated. Forcing Vulkan implementations to do it is wrong-headed.

Vulkan should not make up for lazy OS makers.

[critsec]

Please keep the discussion civil and respectful.

Most "Vulkan implementations" include a usermode graphics driver, a kernel GPU driver, and the GPU hardware. The kernel driver in particular plays an integral role in enforcing the OS security model, and bugs or poor design can lead to holes in that enforcement. The same is true for other graphics APIs. In the past, some kernel graphics drivers have deliberately allowed security holes in the name of performance, e.g. directly mapping GPU control registers to userspace that can be used to make the GPU copy between arbitrary physical addresses.

In the name of performance, Vulkan allows pretty severe consequences when the API is misused, but the spec is intending to make it clear that violating the OS security model is not one of the allowed consequences.

[fluppeteer]

To clarify a distinction: I am strongly in favour that a Vulkan implementation should not allow the security model of the OS to be subverted; as Critsec says, there are performance reasons why this might be seen as desirable, but I think we have agreement that it's unacceptable.

I am not in favour of forcing Vulkan to impose additional security restrictions on an operating system that may not have them. That is, if the Vulkan spec itself said that all data from another process had to be zeroed before use, this would potentially be detrimental to any deeply embedded implementation in an environment where there is no such security model between processes under other circumstances.

Given the Greek theme of Khronos and Vulkan (kind of), I hope we can agree on a Hippocratic Oath: "Do no harm".

I would hope that platforms would be making their own guarantees about what comprises acceptable driver behaviour, too.

[NicolBolas]

In the name of performance, Vulkan allows pretty severe consequences when the API is misused, but the spec is intending to make it clear that violating the OS security model is not one of the allowed consequences.

The OS either has a security model or it doesn't. If the OS doesn't clear memory when it gets freed, then that OS has no such memory security model. In which case, a Vulkan implementation that doesn't clear such memory is violating nothing.

It's wrong for Vulkan to require implementations to offer a security model that is tighter than what the OS provides. Especially when implementing it can impact performance.

[philiptaylor]

I am not in favour of forcing Vulkan to impose additional security restrictions on an operating system that may not have them.

That suggests you also want to remove the spec's existing language about e.g. "implementations must ensure that incorrect usage by an application does not affect the integrity of the operating system", because there are (currently hypothetical?) embedded systems where that's impossible (e.g. ones with no kernel/userspace distinction, or with no MMU).

I think it would be unfortunate to remove all that stuff from the spec entirely, because it's still relevant for the vast majority of implementations, and it seems much easier to argue with a GPU vendor that their Vulkan driver is buggy if you can point to the part of the Vulkan spec that it clearly violates, than if you have to try to explain its conflict with the implications of the OS's probably-undocumented security model. (I think that clarity is especially valuable on Android given the usually terrible lack of caring about security there.)

Maybe the spec could continue to state the requirements for robustness/security/confidentiality/etc, but with an added comment that "These requirements only apply on platforms where it is typically expected that applications will be isolated from one another. On platforms with no such expectations (e.g. some embedded systems), robustness of the Vulkan implementation is only recommended and not required."

[oddhack]

@timofonic it is not helpful to add comments like this to dozens of old issues. Please stop now. We are aware there's an issue backlog, and we get to them as we can and as they are prioritized by companies and members of the Vulkan working group.

[krOoze]

This seem to have been addressed in 1.0.65

[oddhack]

True. I probably overlooked closing it at the time.