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

[Ard Biesheuvel]

On 8 March 2016 at 19:02, Paolo Bonzini <address@hidden> wrote:
>
>
> On 08/03/2016 00:34, Peter Maydell wrote:
>>> > I think that, if UEFI secure boot is in use, the UEFI environment
>>> > variables should also be only accessible from TrustZone, because they
>>> > store the key database.  At least that's how it works on x86, where both
>>> > pflash devices have the secure=on flag.
>> If I understand the setup that is being used correctly, UEFI runs
>> in Non-secure, so making the second flash device secure would mean
>> it could not access it.
>>
>> Ard, do I have that right?
>
> The part of UEFI that accesses variables can (optionally) be moved in
> secure mode.  If you don't do that, secure boot is not secure at all.
> Accesses from non-secure mode do the appropriate marshaling/unmarshaling
> to call into the secure driver.
>
> Again---that's what it does on x86, but restricting variable access to
> the trusted base is an important part of UEFI secure boot.
>

There is currently no implementation for secure boot that moves the
authentication layers into the secure world, not even on actual
hardware (modulo the closed source solutions that we don't have access
to). So our secure boot implementation is interesting as a reference,
since it has all the moving parts in place, but should not be relied
upon as an actual secure environment.

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

-- 
Ard.