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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 07/20/2017 09:52 PM, Tamas K Lengyel wrote:
> 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?

It's been rejected: https://patchwork.kernel.org/patch/9264837/

We need that because we inject a cleanup tool in the guest once a threat
is detected, and we want to be able to know what it is doing. So every
once in a while, the in-guest tool will do a VMCALL that ends up being
an event letting the dom0 application know what it's been up to (a
communication protocol if you will).

We'd be more than happy to retry upstreaming it if I've managed to
explain the need for it better today. :)


Thanks,
Razvan

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