Shared Hypervisor and GPU Admin Path Security Risks

On a shared hypervisor, the provider's host operating system, management plane, and hypervisor sit under the guest that holds the GPU. An administrator on that path can inspect, pause, or reset the guest in ways a neighboring customer process cannot. The neighbor and the admin are different risks. This is an authority argument about who can reach the device. It is not a proof of a specific escape against a named product.

What the Shared Hypervisor Admin Path Can Reach

On a shared hypervisor, the provider's host OS, management plane, and hypervisor sit under the guest that holds the GPU. An administrator on that path can inspect, pause, or reset the guest in ways a neighboring customer process cannot. The neighbor and the admin are different risks.

A virtualized GPU keeps a host under the guest. In the ordinary sense used by GPU clouds, that host is where the hypervisor, the device assignment, and the provider's operators meet. From that position the operator can see guest state the neighboring VM cannot see, can pause the guest, and can reset it. A co-tenant contends for the GPU or for the host's shared services. A co-tenant does not, by being a co-tenant, hold the hypervisor's privileges.

You can have either risk without the other. A noisy neighbor is a performance contention problem on a device you share. The admin path is a privileged operator under every guest on that host, including a host that currently runs only your guest if the hypervisor and the provider's tooling are still there. Separating the two risks is the point of the review. A latency test does not answer the admin-path question, and a list of hypervisor roles does not measure noisy-neighbor jitter.

Why That Path Changes a GPU Purchase

Buy a virtualized GPU when you accept a provider-operated host under the workload and you need fast, fractional capacity. Buy a single-tenant server without a hypervisor when the review must show that no second customer and no hypervisor sit on the GPU's PCIe path.

The purchase changes when the review requirement names who may sit under the workload.

Buy the virtualized GPU when you accept a provider-operated host under the workload and you need capacity in fractions. Buy the single-tenant server without a hypervisor when the review has to show that no second customer and no hypervisor sit on the GPU's PCIe path.

OneSource Cloud removes the shared hypervisor by assigning the GPU as single-tenant bare metal in its own facilities. There is no second customer's guest, and no hypervisor hop, on that PCIe path. The same design still has a facility and a firmware lifecycle. Those belong in the next section, not in a claim that the admin path has gone to zero.

What Bare Metal Does Not Remove

Removing the hypervisor removes that layer. It does not remove the BMC, the firmware, or the people who rack the server. Published firmware research, including Cloudborne-class BMC persistence, is why a bare-metal review still asks how the provider wipes and attests the board between tenants.

Removing the hypervisor removes that layer. It does not remove the baseboard management controller, the firmware, or the people who rack the server. Eclypsium has documented BMC implants, in the class of issues discussed around Cloudborne, that can persist across a tenant handoff if the board is not reflashed. That research is a published risk class for bare-metal handoff. It is not an incident report about OneSource, and it is not evidence that any particular provider has been implanted.

A bare-metal review still asks how the provider wipes and attests the board between tenants, who can reach the BMC, and how firmware updates are authorized. OneSource's approved isolation fact is single-tenant bare metal without hypervisor sharing. It is not a claim that facility operators or firmware do not exist, and it is not a claim of side-channel immunity. Ask to see the wipe and attestation control. Do not accept "bare metal" as a synonym for "no one with administrative access."

The tenancy model those questions attach to is described on the private AI infrastructure page. Use it for the isolation boundary. Use the contract and the firmware procedure for the path bare metal leaves in place.

FAQ

Is a noisy neighbor the same risk as the hypervisor admin path?

No. A noisy neighbor contends for the device. The admin path is a privileged operator under every guest. You can have contention without sharing a hypervisor privilege, and you can have a provider admin path on a host that has no second customer. Measure one with a performance test. Review the other by asking who can inspect, pause, or reset the guest.

How does OneSource remove the shared hypervisor from the GPU path?

OneSource removes the shared hypervisor by assigning single-tenant bare-metal GPUs. Another customer's guest is not on that machine, and a hypervisor is not on the PCIe path to the device. OneSource does not claim the firmware path disappears. Facility operations and the BMC remain controls you should ask to see. They are not a second tenant.