I am going through the Arm Pseudocode for memory translation, and I stumbled upon something that I cannot really explain.
In the functions S2Translate and S2Walk (similar for stage 1) for Aarch64, there are loops that correspond to "repeat until descriptor does not change anymore" (the access flags, dirty bits etc might be changing upon translation, and these changes are written during translation). I was now wondering whether this repeat loop is bounded by some condition. At first sight, I assumed it would be repeated at most once, but I am too ignorant in the realms of Arm to conclude that this is the case.
Intuitively, an adversary can keep changing the descriptor in memory (resetting the accessflag and whatnot), resulting in an infinite loop. Is this actually possible, or are there memory consistency rules or atomicity constraints that I overlooked? If yes (which I assume), can you please point me to what I should read up on? It seems odd that Arm would formulate their specification like this, but also cannot see something preventing a loop (assuming "perfect conditions").
Thank you
AArch64.MemSwapTableDesc is an atomic operation. I cannot image one scenario that how the offending descriptor is repeatedly looped here.
If a malicious actor overwrites a offending descriptor, it is possible. However, the memory attribute check or permission check will figure it out or raise the fault as the bad descriptor. Even though the offending descriptor passes all the checks and goes into S1Translate(), S2Translate() for EL0/EL1, I think it is still finite loops as it obeys the AArch64 VMSA rules.