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

[Ard Biesheuvel]

On 8 March 2016 at 19:10, Ard Biesheuvel <address@hidden> wrote:
> 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
>

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