Re: [RFC v2 00/14] Add SDEI support for arm64

[Heyi Guo <guoheyi@huawei.com>]

On 2020/2/7 18:52, James Morse wrote:
> 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().

Good idea. It seems to be able to cover all the possible the cases, 
while we only need to highlight this exception in the user document :)

Thanks,

Heyi

>
>
>> 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
>
> .