qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v2 08/13] hw/misc/tz_mpc.c: Honour th


From: Peter Maydell
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v2 08/13] hw/misc/tz_mpc.c: Honour the BLK_LUT settings in translate
Date: Fri, 15 Jun 2018 17:07:11 +0100

On 15 June 2018 at 08:31, Auger Eric <address@hidden> 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 <address@hidden>

>> +        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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]