The NS field in PTEs descriptors is tagging Secure/Non-secure physical
memory (pages). This field is relevant in Secure state only:
While in Secure state, software can access both the Secure and
Non-secure physical address spaces, software in Non-secure state can
only access Non-secure memory; the NS bit is hence discarded/treated as
1.
This patch is aligning VMSAv8-32 with VMSAv8-64, which is tagging the
pointed memory as Non-secure in case of a Non-secure lookup.
The old behaviour was probably not leading to incorrect execution:
once a translation completes, the security flag in the memory request
is chcked against the security state of the cpu (and not only relying
on the NS bit in the TLB entry)
if (isSecure && !te->ns) {
req->setFlags(Request::SECURE);
}
so we were already forbidding secure accesses from non secure world
if NS = 0.
It is however misleading in the debug logs to see tlb entries with
NSTID = 1 and NS = 0.
Change-Id: I1f964069f88c33fb14362dd4101cb22538907226
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32638
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
*/
bool secure(bool have_security, WalkerState *currState) const
{
- if (have_security) {
+ if (have_security && currState->secureLookup) {
if (type() == PageTable)
return !bits(data, 3);
else