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

[Jan Kiszka]

On 2015-02-16 15:56, Mark Rutland wrote:
> On Mon, Feb 16, 2015 at 02:31:21PM +0000, Jan Kiszka wrote:
>> On 2015-02-16 15:25, Mark Rutland wrote:
>>> 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.
>>
>> But from a security point of view, it must not matter if the OS maps the
>> memory or not - the monitor must be robust against that, no? If the
>> architecture cannot provide such guarantees, it has to be worked around
>> in software in the monitor (I hope you can do so...).
> 
> Well, yes and no.
> 
> In this case it sounds like due to the security controller you should
> never encounter the mismatched attributes issue in the first place,
> though you may encounter issues w.r.t. speculative accesses triggering
> violations arbitrarily. Not telling the OS about the secure memory means
> that said violations shouldn't occur in normal operation; only when the
> non-secure OS is trying to do something bad.
> 
> If the OS has access to the memory, then you're already trusting it to
> not write to there or you can't trust that memory at all (and hence
> cannot use it). Given that means you must already assume that the OS is
> cooperative, it's simpler to not tell it about the memory than to add
> cache maintenance around every memory access within the monitor. You can
> never make things secure in this case, but you can at least offer the
> abstraction provided by PSCI.
> 
> So as far as I can see in either case it's better to not tell the OS
> about the memory you wish to use from the monitor. If you have no HW
> protection and can't trust the OS then you've already lost, and if you
> do have HW protection you don't want it to trigger
> continuously/spuriously as a result of speculation.

OK, that makes sense again.

Now I just need to figure out how to split/adjust the memory node
instead of adding a reservation region.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux