On Thu, Jul 20, 2017 at 10:57 AM, George Dunlap <george.dun...@citrix.com> wrote: > On 07/20/2017 05:46 PM, Tamas K Lengyel wrote: >> On Thu, Jul 20, 2017 at 10:43 AM, George Dunlap >> <george.dun...@eu.citrix.com> wrote: >>> On Wed, Jul 19, 2017 at 7:24 PM, Tamas K Lengyel <ta...@tklengyel.com> >>> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
