On 15 June 2018 at 08:31, Auger Eric <eric.au...@redhat.com> wrote:
> Hi Peter,
>
> On 06/04/2018 05:29 PM, Peter Maydell wrote:
>> The final part of the Memory Protection Controller we need to
>> implement is actually using the BLK_LUT data programmed by the
>> guest to determine whether to block the transaction or not.
>>
>> Since this means we now change transaction mappings when
>> the guest writes to BLK_LUT, we must also call the IOMMU
>> notifiers at that point.
>>
>> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
>> + if (newlut & (1 << i)) {
> Add a comment saying the block is configured as non-secure?
Sure.
>> + entry.target_as = &s->blocked_io_as;
>> + } else {
>> + entry.target_as = &s->downstream_as;
> so this disallows any secure access to non secure blocks. I have a
> reduced knowledge of TZ but I would have thought that a secure access
> would have sufficient priviledge to access NS memory?
The spec is not as clear as it could be on this point, but...
>> @@ -362,9 +407,10 @@ static IOMMUTLBEntry tz_mpc_translate(IOMMUMemoryRegion
>> *iommu,
>> /* Look at the per-block configuration for this address, and
>> * return a TLB entry directing the transaction at either
>> * downstream_as or blocked_io_as, as appropriate.
>> - * For the moment, always permit accesses.
>> + * If the LUT cfg_ns bit is 1, only non-secure transactions
>> + * may pass. If the bit is 0, only secure transactions may pass.
>> */
...as this comment says, the MPC doesn't permit wrong-secure-state
transactions either way. (This is the same behaviour as for the
Peripheral Protection Controller, whose spec is clearer.)
thanks
-- PMM
