[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case



>>> On 21.03.17 at 17:30, <tamas.lengyel@xxxxxxxxxxxx> wrote:
> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>> supposed to always be available to the guest (as long as altp2m
>> is enabled)? You don't allow this here anymore.
> 
> Absolutely not, that's one of the main reasons why I want the
> external_only option to be available in the first place. For malware
> analysis it is a huge hole if the guest can decide that it wants
> certain EPT violations to be handled by the guest without first going
> to the hypervisor or if it can start switching its EPT tables around.

In which case I guess we need three modes (besides disabled):
- guest can alter permissions
- guest can pick tables
- guest can do nothing

>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -555,10 +555,18 @@ static XSM_INLINE int
>>> xsm_hvm_param_altp2mhvm(XSM_DEFAULT_ARG struct domain *d)
>>>      return xsm_default_action(action, current->domain, d);
>>>  }
>>>
>>> -static XSM_INLINE int xsm_hvm_altp2mhvm_op(XSM_DEFAULT_ARG struct domain 
>>> *d)
>>> +static XSM_INLINE int xsm_hvm_altp2mhvm_op(XSM_DEFAULT_ARG struct domain 
>>> *d, int mode)
>>>  {
>>> -    XSM_ASSERT_ACTION(XSM_TARGET);
>>> -    return xsm_default_action(action, current->domain, d);
>>> +    XSM_ASSERT_ACTION(XSM_OTHER);
>>> +    switch ( mode )
>>> +    {
>>> +    case XEN_ALTP2M_mixed:
>>> +        return xsm_default_action(XSM_TARGET, current->domain, d);
>>> +    case XEN_ALTP2M_external_only:
>>> +        return xsm_default_action(XSM_DM_PRIV, current->domain, d);
>>> +    default:
>>> +        return -EPERM;
>>
>> I think -EPERM is correct at most for XEN_ALTP2M_disabled, all
>> others should get -EINVAL or -EOPNOTSUPP or some such. Perhaps
>> that also doesn't really belong here, but rather into the caller (which
>> right now produces -EINVAL for XEN_ALTP2M_disabled only).
>>
> 
> The reason I want -EPERM here is so that a malicious guest can't
> differentiate between a guest being created with "external_only"
> altp2m and one that has an XSM policy that denies these operations.
> What you propose would lead to information a leak that would make such
> differentiation possible to a malicious guest.

What difference does it make security wise if the guest knows who
denied access? The reason for my comment is that -EPERM does
not correctly reflect the actual error here.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.