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 12:25 PM, Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 07/20/2017 07: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.
>
> It is the case AFAIK. We had to do this trick to allow guest request
> hypercalls coming from guest userspace:
>
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/xen-x86-hvm-Allow-guest_request-vm_events-coming-from-us.patch
>
> By default they can only come from the guest kernel.

Makes sense. Any reason not to have that patch upstreamed?

Tamas

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