Hi guys,
On 06/02/2020 17:30, Marc Zyngier wrote:
On 2020-02-06 01:20, Heyi Guo wrote:
On 2020/2/5 21:15, Marc Zyngier wrote:
My concern is that SDEI implies having EL3. EL3 not being virtualizable
with KVM, you end-up baking SDEI in *hardware*. Of course, this hardware
is actually software (it is QEMU), but this isn't the way it was intended.
It's not the first time we've done that (PSCI is another example), but the
logic behind SDEI looks much more invasive.
Thanks for your comments.
Thinking about them for quite a while, below is my understanding,
please correct me if I'm wrong:
So should the KVM based virtual machine be treated as one with CPUs
only having NS-EL1 and NS-EL0, ideally? And SDEI messes up this model,
isn't it?
Well, that's exactly what it is (until we have nested virt, in which case
you will be able to add NS-EL2 to the mix).
PSCI only contains some one-shot operations, so it is much less
invasive than SDEI.
Is there an established pattern for how Qemu 'gets' things that are done in
secure-world?
For PSCI the kernel does it, but this obviously doesn't scale to something like
OP-TEE.
Ideally we'd get the reference implementation (from ATF) in some form that is
easy to use...
I've another question. The origin of "virtual" SDEI requirement comes
from the lack of hard lockup detector in VM.
(this is your use case. Its origin was just symmetry with EL3<->EL2)
Sure. But nothing guarantees that the guest is going to register a SDEI
entry point anyway.
We can have some kind of
watchdog, but how can the watchdog trigger the VM OS to panic and run
kdump, even in irq-off state?
Nothing. All the events, including SDEI, are maskable, one way or another.
Gavin's approach to inject a SError is probably OK for Linux, given that
it tends to run with PSTATE.A==0. But that's not a guarantee either (if
you take a recursive exception, SError won't be delivered).
Or get stuck in debug-state (for which we mask SError), power-management, the
vectors or
somewhere weird, like KVM's world-switch.
If you just want to kill the OS if its sort-of-alive, there is another trick:
Synchronous exceptions can't be masked because they are caused by the
instruction pointed
to by the ELR. You can't inject an emulated data-abort unless the ELR points to
an
instruction that accesses memory, but...
synchronous external abort for instruction fetch is something that could
happen at any
time. If you have v8.2 you can make the severity uncontainable for extra points.
On real hardware, this would be as if this instruction missed in the i-cache,
then got an
abort from the PoU-cache. The PoU-cache must have suffered some metadata
corruption to
report an uncontained error. On real hardware its very likely the next
instruction would
suffer the same fate, but linux should put up a good show of trying to panic().
The long and the short of it is that there is no way to do what you want
with absolute guarantees on the ARM architecture. It just doesn't exist.
Yes. By sort-of-alive it needs to be making some kind of progress. If the CPU
is spinning
through the vectors (because some joker unmapped them), all bets are off.
Thanks,
James
.