AMD "Cleaner Shader" Coming For GFX11.0.3 GPUs To Help Ensure User/App Isolation

[phoronix]

Phoronix: AMD "Cleaner Shader" Coming For GFX11.0.3 GPUs To Help Ensure User/App Isolation

A new patch posted today for the AMDGPU Linux kernel graphics driver is introducing a "cleaner shader" explicitly for GFX11.0.3 GPUs like the Radeon 780M integrated graphics to help ensure that there is sufficient data isolation between different workloads running on the GPUs. The motivation isn't clear if there is some GFX11.0.3 security vulnerability, some AMD Linux customer particularly concerned about security on said GPUs, or some other motivation for focusing this latest cleaner shader work on GFX11.0.3 hardware...

https://www.phoronix.com/news/AMD-Cleaner-Shader-GFX11.0.3

[Espionage724]

I have a feeling this comes down to being a slower method to do something. Data leaks sounds like a security mitigation, and incorrect computation results sounds like bad driver code on AMD's side that they want to justify on the hardware instead.

Basically, I'm certain this isn't doing anything to improve 3D/game performance, and I'd wager can't be disabled since it's baked into the architecture.

And what is this really to be needing black-box microcode to implement?

[Vermilion]

Sounds like something that would cause a noticeable performance drop.

[illwieckz]

The motivation isn't clear if there is some GFX11.0.3 security vulnerability, some AMD Linux customer particularly concerned about security on said GPUs, or some other motivation for focusing this latest cleaner shader work on GFX11.0.3 hardware.

Michael There is something that affects all GPUs from any brand: when you allocate a framebuffer, it contains existing data, so for example it can contain the content of your terminal window displayed on the same desktop. Then you can capture the framebuffer content and you can run an OCR on it to extract text or do other things. It's not that different to do a malloc on CPU memory and then read the content of the allocated memory. The last time I spoke about it with some graphics driver developers I was told that preventing this would kill performance, and this would be true for any hardware. Also I actually wonder if some AI can be used to help recognizing interesting patterns in said allocated memory.

So I guess it's more about “some AMD Linux customer particularly concerned about security on said GPUs”, I would request that if I was an army (in the same way I would request that every memory allocation on CPU memory should zero the memory before returning the pointer).

[Michael]

Michael There is something that affects all GPUs from any brand: when you allocate a framebuffer, it contains existing data, so for example it can contain the content of your terminal window displayed on the same desktop. Then you can capture the framebuffer content and you can run an OCR on it to extract text or do other things. It's not that different to do a malloc on CPU memory and then read the content of the allocated memory. The last time I spoke about it with some graphics driver developers I was told that preventing this would kill performance, and this would be true for any hardware. Also I actually wonder if some AI can be used to help recognizing interesting patterns in said allocated memory.

So I guess it's more about “some AMD Linux customer particularly concerned about security on said GPUs”, I would request that if I was an army (in the same way I would request that every memory allocation on CPU memory should zero the memory before returning the pointer).

Right, I am just questioning though why only GFX11.0.3 is seeing the special treatment.

[varikonniemi]

Michael There is something that affects all GPUs from any brand: when you allocate a framebuffer, it contains existing data, so for example it can contain the content of your terminal window displayed on the same desktop. Then you can capture the framebuffer content and you can run an OCR on it to extract text or do other things. It's not that different to do a malloc on CPU memory and then read the content of the allocated memory. The last time I spoke about it with some graphics driver developers I was told that preventing this would kill performance, and this would be true for any hardware. Also I actually wonder if some AI can be used to help recognizing interesting patterns in said allocated memory.

So I guess it's more about “some AMD Linux customer particularly concerned about security on said GPUs”, I would request that if I was an army (in the same way I would request that every memory allocation on CPU memory should zero the memory before returning the pointer).

Why would it be expensive to zero the framebuffer when allocated? It's not like you allocate new buffers in a hot path?

[cb88]

Sounds like something that would cause a noticeable performance drop.

It says in the commit it takes about 2500 clocks or roughly 1-1.5 microseconds, so probably inconsequential to you if you need secure workloads.

[cb88]

Why would it be expensive to zero the framebuffer when allocated? It's not like you allocate new buffers in a hot path?

Shaders are cyclic so you'd be doing this protentally every frame... 1.5us and the cache clear would cause noticeable perf drop probably, more so the cache clear. Because whatever else was using that can't come back around and be like oh... my shit is still here lets get it.

[illwieckz]

Why would it be expensive to zero the framebuffer when allocated? It's not like you allocate new buffers in a hot path?

I don't know, I'm not the one who told me that. I'm just reporting what I've heard.

I agree that buffers are not expected to be allocated every now and then, so I would expect this to be somewhat minor (I hope it can be).

[Venemo]

And what is this really to be needing black-box microcode to implement?

The shader ISA is well documented, so this isn't really a black box. You can examine it if you want. The thing is, if they want to use shaders in the kernel, they need to write them in binary because there is no shader compiler inside the kernel.