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 Wed, Jul 19, 2017 at 5:47 AM, Adrian Pop <apop@xxxxxxxxxxxxxxx> wrote:
> Hello,
>
> On Tue, Jul 18, 2017 at 11:26:45AM -0600, Tamas K Lengyel wrote:
>> On Tue, Jul 18, 2017 at 9:25 AM, Adrian Pop <apop@xxxxxxxxxxxxxxx> wrote:
>> > From: Vlad Ioan Topan <itopan@xxxxxxxxxxxxxxx>
>> >
>> > The default value for the "suppress #VE" bit set by set_mem_access()
>> > currently depends on whether the call is made from the same domain (the
>> > bit is set when called from another domain and cleared if called from
>> > the same domain). This patch changes that behavior to inherit the old
>> > suppress #VE bit value if it is already set and to set it to 1
>> > otherwise, which is safer and more reliable.
>>
>> With the way things are currently if the in-guest tool calls
>> set_mem_access for an altp2m view, it implies it wants to receive #VE
>> for it. Wouldn't this change in this patch effectively make it
>> impossible for an in-guest tool to decide which pages it wants to
>> receive #VE for? The new HVMOP you are introducing is only accessible
>> from a privileged domain..
>
> Yes, this change, along with the restrictions from the new HVMOP would
> virtually prevent a guest from changing the suppress #VE bit for its
> pages. The current set_mem_access functionality, if I'm not mistaken,
> is a bit odd since the guest can only clear the sve, but to set it,
> another domain would have to call set_mem_access for it.

Stating that change explicitly in the patch message would have been
something I would want to see.

Calling set_mem_access from the guest itself by design clears the SVE
bit, which makes sense. The in-guest tool doesn't know whether there
is an external mem_access listener, so the only thing it should be
allowed to do is to signal to the hypervisor that when it changes EPT
permissions, violations on those pages need to be injected into the
guest with #VE. If you don't want to allow a domain to make changes
like that, you need to restrict altp2m ops to be issued from the
domain completely.

>
> 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.

Tamas

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