Heh, its "baked in" heh
In all seriousness, I wonder what the actual issue is.
Could anyone comment as to the implications of only supporting a Type 2 hypervisor that is (as said on the site) "in violation of the ARMv8 specification"?
In all seriousness, I wonder what the actual issue is.
Could anyone comment as to the implications of only supporting a Type 2 hypervisor that is (as said on the site) "in violation of the ARMv8 specification"?
It's just a very unfortunate coincidence that precisely that support would allow this bug to be trivially mitigated on Linux. (Wouldn't help macOS, as they'd have to implement this from scratch anyway; it's just that existing OSes that support this mode could use it).
The actual issue is just what I described: the hardware implementation of this register neglects to check for and reject accesses from EL0 (userspace). It's a chip logic design flaw. I don't know exactly where it is (whether in the core/instruction decoder, or in the cluster component that actually holds the register, depending on where they do access controls), but either way that's what the problem is.
This one is a minor side note but there could be other vulnerabilities that could be resolved if the specifications were followed (I assume).
So it's not that not following the spec prevents the workaround, it's just that had they followed the spec it would just take a single kernel command line argument (to force non-VHE mode) to fix this in Linux, while instead, now we'd have to make major changes to KVM to make the non-VHE code actually work with VHE, and really nobody wants to do that just to mitigate this silly thing.
Had this been a more dangerous flaw (e.g. with DoS or worse consequences), OSes would be scrambling to make major reworks right now to mitigate it in that way. macOS would have to turn its entire hypervisor design on its head. Possible, but not fun.