On 31 October 2015 at 03:40, Peter Crosthwaite <crosthwaitepe...@gmail.com> wrote: > On Fri, Oct 30, 2015 at 2:14 PM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 30 October 2015 at 20:59, Peter Crosthwaite >> <crosthwaitepe...@gmail.com> wrote: >>> On Fri, Oct 30, 2015 at 1:49 PM, Peter Maydell <peter.mayd...@linaro.org> >>> 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
