Hacker News Reader

Comment by kdrag0n | Hacker News Reader

In the Android 13 bootloader and firmware for Tensor, Google added the ability to expose the EL2 hypervisor privilege level to the kernel for their protected KVM feature (pKVM). Protected VMs seem to be an optional feature, however, so full KVM access is available as far as I can tell.

On Qualcomm SoCs, EL2 is occupied by their HypX hypervisor, so KVM is impossible without exploiting HypX. I don't think OEMs are allowed to do much about it, and it seems to be a somewhat integral part of their platform, so removing it would likely be a big undertaking even if OEMs were allowed to do so.

On Exynos SoCs, the kernel boots in EL1, but Samsung has a security feature called RKP that involves loading code in EL2. This means that it's theoretically possible to hack it up for enabling KVM, but KVM doesn't just work out-of-the-box.

I'm not sure about other SoC vendors, but the most popular one by far (Qualcomm) effectively makes KVM impossible.

View on HN

A note:

> On Qualcomm SoCs, EL2 is occupied by their HypX hypervisor, so KVM is impossible without exploiting HypX. I don't think OEMs are allowed to do much about it, and it seems to be a somewhat integral part of their platform, so removing it would likely be a big undertaking even if OEMs were allowed to do so.

For Chrome OS firmware stack, full EL2 is given to the kernel, the regular way.

For the Windows on Arm64 stack (on currently shipped SoCs), a mechanism, Secure Launch, is provided to escalate from EL1 to EL2. bootmgfw issues a SMC call, the function is the same as the one used to initialise Intel ACM or AMD SKINIT. QHEE intercepts it, does some sanity and integrity checks then remaps memory to load the TCB launcher and jumps to the entry point. This means that if you run Linux on those, you don't have EL2.

It's a real shame the number of privilege levels is fixed. This seems anti-turing-completeness. Instead, any VM or hypervisor should be able to emulate an environment that is indistinguishable from the environment it itself is running in. That in turn means that hypervisors must be infinitely nestable, and there must be no way for software to know that is running in an emulated environment (unless the hypervisor above wants to reveal this info).

I get that 'infinitely nestable' is hard to implement in hardware, and it's much easier to design things with a fixed nesting depth/number of privilege levels, but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability without too much of a performance hit.

To get any sort of reasonable performance you need paravirtualized devices, at least on x86.

> but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability

Nested virtualisation is available for server cores starting from Neoverse V1 onwards, but not for Cortex…

(Also, EL0 could be used as a problem state for this, but some complexities associated to that make it awkward. Unlike POWER (which does have KVM-PR), VBAR doesn’t link to a physical address)

For more background on the technical details, I found this presentation describing how KVM works with Arm EL2: https://events.static.linuxfound.org/sites/events/files/slid... (pdf)

Thank you for the elaborate answer, and for your admirable work.

Reply on news.ycombinator.com