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.