[U-Boot] [PATCH 6/8] ARMv8: PSCI: Fixup the device tree for PSCI v0.2

[Mark Rutland]

On Mon, Sep 01, 2014 at 07:43:18PM +0100, Mark Rutland wrote:
> Hi,
> 
> > >> diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
> > >> index 9792bc0..c2c8fe7 100644
> > >> --- a/arch/arm/cpu/armv8/cpu-dt.c
> > >> +++ b/arch/arm/cpu/armv8/cpu-dt.c
> > >> @@ -9,7 +9,69 @@
> > >>   #include <fdt_support.h>
> > >>
> > >>   #ifdef CONFIG_MP
> > >> +#ifdef CONFIG_ARMV8_PSCI
> > >>
> > >> +static void psci_reserve_mem(void *fdt)
> > >> +{
> > >> +#ifndef CONFIG_ARMV8_SECURE_BASE
> > >> +	/* secure code lives in RAM, keep it alive */
> > >> +	fdt_add_mem_rsv(fdt, (unsigned long)__secure_start,
> > >> +			__secure_end - __secure_start);
> > >> +#endif
> > >> +}
> > >
> > > With PSCI I'd be worried about telling the OS about this memory at all.
> > >
> > > If the OS maps the memory we could encounter issues with mismatched
> > > aliases and/or unexpected hits in the D-cache, which can result in a
> > > loss of ordering and/or visbility guarantees, which could break the PSCI
> > > implementation.
> > >
> > > With the KVM or trusted firmware PSCI implementations the (guest) OS
> > > cannot map the implementation's memory, preventing such problems. The
> > > arm64 Linux boot-wrapper is dodgy in this regard currently.
> > >
> > 
> > The idea here is that if there is no PSCI specific (most likely secure) 
> > memory allocated in the system, the macro "CONFIG_ARMV8_SECURE_BASE" 
> > will not be defined. In this case the PSCI vector table and its support 
> > code will be in DDR and will be protected from Linux using memreserve.
> 
> Sure, this will prevent the OS from explicitly modifying this memory.
> 
> However, the OS will still map the memory. This renders the protection
> incomplete due to the possibility of mismatched attributes and/or
> unexpected cache hits resulting in nasty coherency problems. We are
> likely to get away with this most of the time (if the kernel and U-Boot
> use the same attributes), but it would be very easy to blow things up
> accidentally.
> 
> The only way to prevent that is to completely remove a portion of the
> memory from the view of the OS, such that it doesn't map the memory at
> all.

To clarify:

If the PSCI implementation uses some memory not described to the OS
there is no problem. Ideally this would be some secure SRAM somwhere,
which the OS can never map. So if you are using some secure RAM then
there is no issue.

If the memory is described to the non-secure OS, then there can be
coherency issues unless either:

 * The caches are not in use at EL3. This necessitates something like
   bakery locks for synchronization.

 * The memory is mapped at EL3 as secure, and the core makes a
   distinction between secure and non-secure memory (see
   ID_AA64MMFR0_EL1.SNSMem). Otherwise misatched attributes can cause
   coherency issues (see B2.9 "Mismatched memory attributes" in the ARM
   ARM).

Thanks,
Mark.