Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 10/03/17 07:34, Jan Beulich wrote:
>>>>> On 09.03.17 at 18:29, <tamas@xxxxxxxxxxxxx> wrote:
>>> On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> However - is this interface supposed to be usable by a guest on itself?
>>>> Arguably the same question would apply to some of the other sub-ops
>>>> too, but anyway.
>>> AFAIK the only op the guest would use on itself is
>>> HVMOP_altp2m_vcpu_enable_notify.
>> Which then means we should move all of them out of here, into a
>> suitable domctl. That will in turn reduce the scope of the bogus
>> interface versioning, which Andrew did point out, quite a bit.
>
> The original usecase for altp2m was for an entirely in-guest agent,
> which is why they got in as hvmops to start with.  I don't think it is
> wise to break that.
>
> I think there needs to be slightly finer grain control, identifying
> whether a domain may use altp2m, and whether it may configure altp2m
> permissions itself.
>
> The nature of altp2m means that using EPTP switching/etc necessarily can
> only happen from inside guest context, but whether you trust the domain
> to make adjustments to the permissions itself depends on your usecase
> and threat model.
>

So I'm actively using EPT switching and gfn remapping from a
privileged monitor domain (not with VMFUNC). My entire usecase for
altp2m is purely external without any in-guest agents. In fact, I have
to deploy a custom XSM policy to blacklist altp2mhvm_op being issued
from the guest.

The reason I mentioned HVMOP_altp2m_vcpu_enable_notify as being the
only one I believe that is only accessible from within the guest is
this distinction in arch/x86/hvm/hvm.c:

    d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
        rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();

For the other ops I'm not sure if they were really required to be
accessible from within the guest or not. I'm not even sure using them
would work from the guest with the above check in place. However, if
they do work from the guest then I have no idea how it was supposed to
work for security purposes as any application in that guest could just
issue a hypercall to manipulate it or even turn it off.

Tamas

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