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

[Mark Rutland]

On Thu, Feb 19, 2015 at 10:13:58AM +0000, Ian Campbell wrote:
> On Thu, 2015-02-19 at 10:25 +0100, Jan Kiszka wrote:
> > On 2015-02-19 10:19, Ian Campbell wrote:
> > > On Thu, 2015-02-19 at 09:28 +0100, Thierry Reding wrote:
> > >> On Tue, Feb 17, 2015 at 11:55:24AM +0000, Mark Rutland wrote:
> > >>> [...]
> > >>>
> > >>>>>> This is getting invasive:
> > >>>>>>
> > >>>>>> If I add carveouts via adjusting memory banks, I need to account for the
> > >>>>>> case that an existing bank is split into two halves, creating additional
> > >>>>>> banks this way. But then current fdt_fixup_memory_banks will no longer
> > >>>>>> work due to its limitation to the number of physical banks. I could
> > >>>>>> always add one spare bank to that service, ok, but then the next use
> > >>>>>> case for carveouts will hit the wall again. So I better double that
> > >>>>>> limit, or so.
> > >>>>>
> > >>>>> Yeah, not fun.
> > >>>>>
> > >>>>> If the code is position-independent then you might be able to simply
> > >>>>> carve out a sufficient proportion from the start of the first entry or
> > >>>>> the end of the last one, which would avoid splitting. If either of said
> > >>>>> regions are too small for the monitor code then it's questionable as to
> > >>>>> whether the OS can make use of it.
> > >>>>
> > >>>> The code /seems/ to be position-independent, but locations are so far
> > >>>> hard-coded in those places that prepare it and move it around. Maybe we
> > >>>> can decide about the location at runtime, maybe we can simply demand it
> > >>>> to be at the end or the beginning of some bank.
> > >>>
> > >>> If it's possible to do so, it would seem like the nicest option to me.
> > >>
> > >> Using the top of memory for this seems like the most natural choice,
> > > 
> > > I think it needs to still be below 4G, doesn't it? So on large mem/LPAE
> > > systems some care might be needed.
> > 
> > Argh. That would likely mean we had to split a bank (unless >2G comes in
> > multiple banks), something I'd like to avoid having to implement.
> 
> I expect it is usual for the 4G boundary to coincide with a bank
> boundary, even if memory spans the gap -- but I also don't think we can
> rely on that.
> 
> > > It was suggested by Mark earlier in the thread that this stuff is
> > > IMPLEMENTATION DEFINED. Is it possible that we simply don't need to
> > > worry about these cross-world cache issues on Tegra?
> > > 
> > > (I must confess that until now I'd assumed that the cache lines were
> > > tagged with the world which populated them to stop them interfering with
> > > each other in this sort of way...)
> > 
> > I'm pretty sure that is no such thing as a cross-world cache problem.
> > Otherwise the architecture or some implementation would have serious
> > security issues as discussed earlier. To my understanding, Mark's
> > suggestion is now targeting the concern that Linux may accidentally
> > trigger accesses and, thus, stumble or create warnings at least.
> 
> Ah, then I've misunderstood/misremembered.
> 
> I think it is fair to say that if a NS-world OS deliberately touches a
> region marked reserved or not described at all then it deserves whatever
> fault it gets. But I think what Mark is saying is that just mapping the
> region but never explicitly accessing it can still result in errors due
> to e.g. prefetching or speculative behaviour which may use those
> mappings.

In this case the external memory security controller block likely can't
tell the difference (speculative and explicit accesses will look the
same on the bus). So any speculative access can trigger violations and
bring down the non-secure world (or just DoS the secure world if it
signals the secure world but provides a dummy result to non-secure
reads).

> IOW it is architecturally allowable for faults arising from accesses
> never explicitly occurring in the code to result in OS visible faults.
> Rather than, say, requiring such faults to be squashed until the
> real/non-speculative access actually really occurs in the program.

Yes. Anything mapped cacheable (or non-executable) can be speculatively
read, and if those accesses trigger some error on the bus (e.g. due to a
security controller), you'll get some kind of asynchronous abort
reported by the CPU.

Thanks,
Mark.