Re: [Xen-devel] [PATCH v3 1/2] x86/mm: Change default value for suppress #VE in set_mem_access()

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Jul 20, 2017 at 11:03 AM, Tamas K Lengyel <tamas@xxxxxxxxxxxxx> wrote:
> On Thu, Jul 20, 2017 at 10:57 AM, George Dunlap
> <george.dunlap@xxxxxxxxxx> wrote:
>> On 07/20/2017 05:46 PM, Tamas K Lengyel wrote:
>>> On Thu, Jul 20, 2017 at 10:43 AM, George Dunlap
>>> <George.Dunlap@xxxxxxxxxxxxx> wrote:
>>>> On Wed, Jul 19, 2017 at 7:24 PM, Tamas K Lengyel <tamas@xxxxxxxxxxxxx> 
>>>> wrote:
>>>>>> I think the issue would be whether to allow a domain to set/clear the
>>>>>> suppress #VE bit for its pages by calling the new HVMOP on itself.
>>>>>
>>>>> This problem is not limited to setting the SVE bit. It also applies to
>>>>> swapping altp2m views. Pretty much all altp2m HVMOPs can be issued
>>>>> from a user-space program without any way to check whether that
>>>>> process is allowed to do that or not. If you don't think it is safe
>>>>> for a domain to set SVE, the none of the altp2m ops are safe for the
>>>>> domain to issue on itself. If we could say ensure only the kernel can
>>>>> issue the hvmops, that would be OK. But that's not possible at the
>>>>> moment AFAICT.
>>>>
>>>> Wait, is that right?  I think we normally restrict hypercalls to only
>>>> being made from the guest kernel, don't we?
>>>>
>>>
>>> If that's the case then it's good to know (can you point me where that
>>> restriction is done?) I was just referring to the fact that
>>> technically a userspace program can issue VMCALL.
>>
>> Well for vmcall in particular, it's in
>> xen/arch/x86/hvm/hypercall/hvm_hypercall().  The check for PV guests is
>> in xen/arch/x86/x86_64/entry.S:lstar_enter.  Other checks are left as an
>> exercise for the reader. :-)
>
> Thanks ;) I'm looking through it.

All checks out, we can ignore my concerns above. (Some comments around
vmx_get_cpl would have been helpful, took me a bit to find in the
manual why the bitshift is needed)

Tamas

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