Hi George,
On 15/12/16 04:54, George Dunlap wrote:
On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall <julien.gr...@arm.com> wrote:
Note that ARM does not provide any hardware instruction to translate
an IPA (guest physical address) to a PA. So we have a walker there.
We also a walk for debugging guest page table (though only when it is
using LPAE). I guess it could be re-used in the case where it is not
possible to do it in hardware. Although, it would be rewritten to make
it safe.
This sounds like the kind of thing which would be generally useful,
although I'd like to understand the problem better before making
suggestions.
memaccess will restrict permission of certain memory regions in stage-2 page
table. For the purpose of the example, lets say read-access as been
restricted.
One of these memory regions may contain the stage-1 page table. Do you agree
that the guest will not able to read stage-1 page table due the restriction?
But only if the memory is read-protected, right? If a guest PT
(stage-1) has read permission but not write permission, the hardware
walker should still work, shouldn't it?
Good question, ARMv8.1 is adding support of hardware management for the
access flag and dirty state (see chapter B4 in DDI0557A.b). So if the
hardware has to update the page table entry it would need write permission.
I have looked at the pseudo code for the address translation in both
ARMv8.0 and ARMv8.1.
ARMv8.0 does not need to update the table entry in hardware, looking at
the AArch64.CheckS2Permission pseudo-code (see J1-5290 in ARM DDI
0486A.k_iss10775), the hardware walk will check whether stage-2 as read
permission during Stage 1 page table walk (s2fs1walk variable is to true).
For ARMv8.1, after spending a couple of hours reading the pseudo-code
(see E.1.2.5 in DDI0557A.b) my understanding is the hardware walker may
need to update the entry (see AArch64.CheckAndUpdateDescriptor). This is
depending on who has triggered the walker (e.g address translation
instruction, instruction fetch, memory access...). In the case of
address translation instruction (AccType_AT) no hardware update will be
done.
So to answer your question, the address translation instruction only
need read access. So the issue mentioned would only happen when the
memory is read-protected.
Reading the pseudo-code reminded me a potential upcoming error with
memaccess. I mentioned it a couple of months ago (see [1] and the KVM
counterpart [2]) on the ML. Stage-2 permission fault during stage-1
walk, the syndrome field WnR (Write not Read) will report whether the
abort was caused by a write instruction or read instruction. And not
whether the hardware walker was reading or writing the page table entry.
This is pretty obvious with the new pseudo-code for
AArch64.CheckPermission in the spec (see J1-5290 in ARM DDI
0486A.k_iss10775).
I think that a guest having stage-1 page table protected in stage-2
could be stuck forever faulting and retrying a write instruction because
memaccess would receive the wrong fault (i.e write fault instead of read).
Cheers,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg00228.html
[2]
https://lists.cs.columbia.edu/pipermail/kvmarm/2016-September/021925.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel