Re: [Qemu-arm] [PATCH 0/4] virt: provide secure-only RAM and first flash

[Ard Biesheuvel]

On 8 March 2016 at 19:41, Paolo Bonzini <address@hidden> wrote:
>
>
> On 08/03/2016 13:16, Ard Biesheuvel wrote:
>> > > > As far as this QEMU port is concerned, having some flash in secure and
>> > > > some in non-secure is going to be useful regardless, and 64 MB is
>> > > > plenty for both the code and the data. So if users of the Trustzone
>> > > > port (which is disjoint from the KVM port in any case) can tolerate
>> > > > having the code and the variables in the same pflash file, I could
>> > > > simply move the code into the second flash, and we could reserve the
>> > > > first flash for secure (so it sits at physical address 0x0
>> > >
>> > > Uhm, actually, the code is not even in the flash to begin with. So
>> > > having the second bank be non-secure only makes perfect sense imo
>> >
>> > Interesting, where is the code?
>>
>> The UEFI code is loaded into DRAM by the secure firmware, and
>> relocated and executed from there.
>
> And if (as in the closed source implementations) UEFI had access to
> TrustZone, would the privileged parts of the code be moved to secure DRAM?
>

Yes. There are various ways imaginable to implement this on ARM/arm64,
either based on ARM Trusted Firmware, or on a full PI implementation
that owns all privileged exception levels and the secure side.
However, this is an unsolved problem on ARM, i.e., the [S]MM support
is in the paper phase, sadly.

> Still, the UEFI code must still be protected from tampering, so it
> should also reside in secure flash.
>

Yes. We have a fairly good picture of how we should implement it if
there were such things as an SMM runtime and other things that could
help us implement the plumbing below the UEFI Runtime Services in a
way where all the reasoning about the authenticity of the variable
updates occurs in the secure world. The same applies for having tamper
proof flash to put the code. The problem is that none of that has been
specified yet, so while we have some proof of concept draft stuff,
there is no point yet in taking this much further until the architects
make their minds up.

Note that, for KVM, it is unlikely that we will ever support all of
this inside the guest. It makes *much* more sense to lock down the
emulated flash, and implement the UEFI Runtime Services using a thin
layer in UEFI that hooks up to interfaces exposed to the guest by
QEMU.