Re: [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

[Julien Grall <julien.grall@arm.com>]

Hi George,

On 15/12/16 04:54, George Dunlap wrote:
> On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall <julien.grall@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