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

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

Hello Tamas,

On 12/12/16 23:47, Tamas K Lengyel wrote:
> On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 12/12/2016 19:41, Tamas K Lengyel wrote:
>>> On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall <julien.grall@arm.com>
>>> wrote:
>>>> On 12/12/16 18:42, Tamas K Lengyel wrote:
>>>>> On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall <julien.grall@arm.com>
>>>>> wrote:
>>> I see. So IMHO this is not a problem with mem_access in general, but a
>>> problem with a specific application of mem_access on ARM (ie.
>>> restricting read access to guest pagetables). It's a pitty that ARM
>>> doesn't report the IPA automatically during a stage-2 violation.
>>
>>
>> I don't understand what you are asking for here. If you are not able to
>> access stage-1 page table how would you be able to find the IPA?
>
> I'm not asking for anything, I'm expressing how it's a pity that ARM
> CPUs are limited in this regard compared to x86.

Give a look at the ARM ARM before complaining. The IPA will be provided 
(see HPFAR) on a stage-2 data/prefetch abort fault.

>
>>
>> It works on x86 because, IIRC, you do a software page table walking.
>> Although, I don't think you have particular write/read access checking on
>> x86.
>
> I don't recall there being any software page walking being involved on
> x86. Why would that be needed? On x86 we get the guest physical
> address recorded by the CPU automatically. AFAIK in case the pagetable
> was unaccessible for the translation of a VA, we would get an event
> with the pagetable's PA and the type of event that generated it (ie.
> reading during translation).

You are talking about a different thing. The function 
p2m_mem_access_check_and_get_page is only used during copy_*_guest 
helpers which will copy hypercall buffer.

If you give a look at the x86 code, for simplicity let's focus on HVM, 
the function __hvm_copy will call paging_gva_to_gfn which is doing the
table walk in software (see arch/x86/mm/hap/guest_walk.c). No hardware 
instruction like on ARM...

Although, it looks like that there is hardware instruction to do address 
translation (see nvmx_hap_walk_L1_p2m), but only for nested 
virtualization. And even in this case, they will return the IPA (e.g 
guest PA) only if stage-1 page table are accessible.

>
>>
>>> A way to work around this would require mem_access restrictions to be
>>> complete removed, which cannot be done unless all other vCPUs of the
>>> domain are paused to avoid a race-condition. With altp2m I could also
>>> envision creating a temporary p2m for the vcpu at hand with the
>>> restriction removed, so that it doesn't affect other vcpus. However,
>>> without a use-case specifically requiring this to be implemented I
>>> would not deem it critical.
>>
>>
>> I suggested a use-case on the previous e-mail... You are affected today
>> because Linux is creating hypercall buffer on the stack and heap. So the
>> memory would always be accessed before. I could foresee guest using const
>> hypercall buffer.
>>
>>> For now a comment in the header describing
>>> this limitation would suffice from my perspective.
>>
>>
>> So you are going to defer everything until someone actually hit it? It might
>> be time for you to focus a bit more on other use case...
>>
>
> Yes, as long as this is not a critical issue that breaks mem_access
> and can be worked around I'll postpone spending time on it. If someone
> finds the time in the meanwhile to submit a patch fixing it I would be
> happy to review and test it.

I will be happy to keep the memaccess code in p2m.c until I see a strong 
reason to move it in a separate file.

Your sincerely,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel