[U-Boot] [PATCH v2 06/12] virt-dt: Allow reservation of the secure region when it is in a RAM carveout.

[Mark Rutland]

On Mon, Feb 16, 2015 at 01:51:37PM +0000, Jan Kiszka wrote:
> On 2015-02-16 14:42, Mark Rutland wrote:
> > On Mon, Feb 16, 2015 at 12:54:43PM +0000, Jan Kiszka wrote:
> >> From: Ian Campbell <ijc at hellion.org.uk>
> >>
> >> In this case the secure code lives in RAM, and hence needs to be reserved, but
> >> it has been relocated, so the reservation of __secure_start does not apply.
> >>
> >> Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to reserve such a
> >> region.
> >>
> >> This will be used in a subsequent patch for Jetson-TK1
> > 
> > Using a memreserve and allowing the OS to map the memory but not poke it
> > can be problematic due to the potential of mismatched attributes between
> > the monitor and the OS.
> 
> OK, here my knowledge is not yet sufficient to process this remark. What
> kind of problems can arise from what kind of attribute mismatch? And why
> should the OS be able to cause problems for the monitor?

For example, consider the case of the region being mapped cacheable by
the OS but not by the monitor. The monitor communicates between cores
expecting to never hit in a cache (because it uses a non-cacheable
mapping), but the mapping used by the OS can cause the region to be
allocated into caches at any point in time even if it never accesses the
region explicitly.

The CPU _may_ hit in a cache even if making a non-cacheable access (this
is called an "unexepcted data cache hit"), so the cache allocations
caused by the OS can mask data other CPUs wrote straight to memory.

Other than that case, I believe the rules given in the ARM ARM for
mismatched memory attributes may apply for similar reasons.  Thus
allowing the OS to map this memory can cause a loss of coherency on the
monitor side, if the OS and monitor map the region with different
attributes.

This is all IMPLEMENTATION DEFINED, so it may be that you're fine on the
system you're dealing with. I don't immediately know whether that is the
case, however. Never telling the OS about the memory in the first place
avoids the possibility in all cases.

> > If you're able to carve out the "secure" memory from the memory node(s),
> > then you should be safe from that.
> 
> Do you have a pointer to an example how to do it instead?

Unfortunately not; I don't know whether there's an existing primitive
for doing that. In general you might need to split a memory region in
two to carve out the portion in the middle.

Thanks,
Mark.