Zluda 6 unpins CUDA from Nvidia hardware

Zluda 6 has been released. It runs unmodified CUDA applications on non-Nvidia GPUs. That is the fact, and it is the only fact that matters for this briefing. CUDA is NVIDIA-optimized code. It now executes on hardware it was not written for, with no modification to the application. Whether this capability has been turned against any production system is not confirmed. The capability itself is confirmed, and that is enough to open the question.

I am not interested in the engineering. The implementation is an engineering problem and it belongs to engineers. My concern is narrower and it does not move: identity, access, execution context, and the trust relationships built on top of them. The relevant question is not how Zluda 6 works. It is which assumptions stop holding when NVIDIA-optimized code no longer requires NVIDIA hardware to run.

Hold the boundaries of what is established. Known: unmodified CUDA applications run on non-Nvidia GPUs. Implied, as a logical necessity: any control that treated the pairing of CUDA code and NVIDIA hardware as fixed is now operating on a premise that is no longer reliable. Not confirmed: that this has been exploited, the techniques any attacker would use, the number of systems affected, dwell time, or scale of impact. None of those are stated, so none of those exist for the purposes of this briefing. Absence of that data is itself a condition, and I will treat it as one.

The assumption under examination is simple and it was rarely stated out loud. CUDA applications run on NVIDIA hardware. The hardware and the software were treated as a single unit. For most environments the pairing was not a decision. It was a default that nobody chose and nobody enforced, because the platform appeared to enforce it on their behalf.

That default was load-bearing in places it was never designed to support. Where a system inventoried workloads, scoped trust, or reasoned about an environment using the presence of CUDA code as a proxy for a specific hardware substrate, the hardware was being used as a boundary. The reasoning ran in one direction. This is a CUDA workload, therefore it requires NVIDIA hardware, therefore it can only exist in places we already account for. Which specific systems reasoned this way is not confirmed. That the reasoning was available to be made is established by the facts.

A boundary that is assumed and not enforced is not a boundary. If any environment scoped trust to the hardware-software pairing, that scoping was a convenience that held only as long as the pairing held. It was never a control, because nothing enforced it. The platform’s behaviour was mistaken for an enforcement point. Identity is the boundary. Hardware is not identity, and a property of the runtime is not an access decision. Any design that let the two blur was exposed the moment the pairing stopped being fixed.

Zluda 6 removes the pairing. Unmodified CUDA applications now run on non-Nvidia GPUs. The directional reasoning above no longer completes. The presence of CUDA code no longer implies NVIDIA hardware, and it no longer implies the bounded set of locations that assumption carried with it. The signal is broken. It does not degrade. It is no longer a reliable signal at all.

The observable consequence is a widened execution context. Applications that were assumed to run only on one class of hardware can now run on another, without being changed. Any system utilizing those applications now has an execution surface larger than the one it was scoped against. The facts state the requirement directly. This demands immediate scrutiny of every system utilizing those applications. That is not a recommendation. It is the position. The scope of scrutiny is defined by the scope of usage, and usage is the only variable left that the operator controls.

What this changes is a trust boundary, and the boundary is now exposed. What is not confirmed is that the boundary has been crossed. There is no stated incident, no stated technique, no stated victim. Do not read this as an account of an attack, because no attack is in evidence. Read it as a condition. A trust relationship that depended on NVIDIA-optimized code requiring NVIDIA hardware no longer has anything underneath it. The work that follows is to find every place that dependency was assumed, and to decide what must now be true instead.

The failure mechanism is substitution. A property of the runtime stood in for an enforced boundary. The presence of CUDA code was read as the presence of NVIDIA hardware, and the presence of NVIDIA hardware was read as a bounded set of accounted-for locations. None of those reads were checks. They were inferences that completed on their own because the platform had behaved consistently. Observable behaviour now contradicts the chain. Unmodified CUDA applications execute on non-Nvidia GPUs. The first inference is false, and every inference downstream of it inherits the falsehood.

This failure does not announce itself. Nothing errors. The application runs. Output is produced. A system scoped to the old pairing keeps operating and keeps reporting success, because the only thing that changed is the hardware underneath an unchanged binary, and the binary was never the thing being checked. The widened execution context is observable only if something was watching the hardware substrate directly. Whether any system was watching at that level is not confirmed. What is confirmed is that the application no longer requires the hardware it was assumed to require.

Name precisely what broke. Not the application. Not the hardware. The link between them, which was never a control and was carrying the weight of one. A control fails loud or it fails closed. This failed silent and open. Code scoped to one hardware class now runs on another with no modification and no signal. The boundary that was assumed is gone, and its absence produces no event. Absence of an event is the condition. It is not evidence that nothing changed.

The pattern is the use of an inferred property as a stand-in for an enforced one. Wherever a system reasons that this artifact implies that substrate, therefore that location, therefore that trust level, the whole chain rests on the first implication holding. The implication is not enforcement. It is an observation that has been reliable, and reliability gets mistaken for a guarantee. The moment the observed property becomes reproducible somewhere it was not expected, every decision keyed on it returns a confident wrong answer.

The mechanism repeats anywhere a default pairing is treated as fixed. The specific pairing here is CUDA code and NVIDIA hardware. The shape is general. A thing that was hard to move was assumed to be unmovable, and that assumption was wired into how trust was scoped. When portability is introduced, the wiring does not update. It keeps producing the conclusion it was built to produce, against facts that no longer support it. The artifact still looks the same. Only the constraint that made it meaningful is gone.

This is the same mechanism as any boundary drawn around a property the system does not itself enforce. If the constraint is held in place by something outside the system’s control, the system does not own the boundary. It is renting it from the platform, and the lease can end without notice. Zluda 6 ended one such lease. The decoupling of CUDA code from NVIDIA hardware is the specific event. The exposure is every place an unenforced constraint was load-bearing.

The pairing of CUDA code and NVIDIA hardware was never a control, and anything that depended on it now stands on nothing. Identity is the boundary. Hardware is not identity. A property of the runtime is not an access decision. Any place where those were allowed to blur is exposed now, whether or not anything has acted on the exposure. Exposure is a state. It does not require an attacker to be present to be real.

What must now be true is direct. Every system utilizing these applications is in scope for scrutiny, and the scope of scrutiny equals the scope of usage. The facts state that demand. It is not conditional on confirmation of an incident, because the condition that creates the demand is the capability, not its use. Whether the capability has been turned against any system is not confirmed. The requirement does not wait on that confirmation.

If a system allows CUDA code to run on non-Nvidia hardware, it will run there. That is not a forecast. It is what the word allows means. Controls that are not enforced are not controls, and a boundary that held only because nobody had decoupled the pairing was never holding anything. The pairing is decoupled. The one variable left under operator control is which systems use these applications and what trust those systems still extend on the old assumption. Define that, or operate blind to an execution surface that has already widened.