Re: [Qemu-devel] [PATCH v2 4/5] arm: boot: Add secure_board_setup flag

[Peter Maydell]

On 31 October 2015 at 03:40, Peter Crosthwaite
<address@hidden> wrote:
> On Fri, Oct 30, 2015 at 2:14 PM, Peter Maydell <address@hidden> wrote:
>> On 30 October 2015 at 20:59, Peter Crosthwaite
>> <address@hidden> wrote:
>>> On Fri, Oct 30, 2015 at 1:49 PM, Peter Maydell <address@hidden> wrote:
>>>> Is it an error for the board to set secure_board_setup if
>>>> the CPU doesn't have EL3? (if so, worth mentioning in this
>>>> comment; maybe assert?)
>>>>
>
> Does the same apply to secure_boot flag as well? I can't see any
> guarding or erroring out there. secure_boot is simply ignored when
> there is no EL3, and the same if on EL3 will apply to this new flag as
> well. If we need to fix this, we should fix them both together.

I started off this reply agreeing with you that we should fix both
of them. But then I realised that the two cases are actually different.

Our only current board that sets secure_boot is the vexpress
board, and the A15 version of that can happily boot in
non-secure or secure, because it doesn't need any SMC entry
points. So it works with KVM. (The A9 flavour wouldn't, but
KVM doesn't support A9 guests anyway.) That means that whether
secure_boot is in conflict with KVM or no-EL3 is a board
level decision (and it sounds like on highbank it should
perhaps be an error, though I have a feeling that suitably
configured kernels should be able to run in KVM, so perhaps not).

On the other hand, the secure_board_setup flag means the
board-blob must be relying on EL3 actually existing and
working (otherwise it would have provided a blob that worked
even in NS and not bothered setting secure_board_setup).
So "secure_board_setup + (KVM or no EL3) == error" is always
true for any board, and can be checked in boot.c.

So I think:
 * secure_boot + KVM is OK (or if it's not, it's the board
   code's job to error out)
 * secure_board_setup + KVM is not OK

thanks
-- PMM