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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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

Why do you think those other two modes would be needed? I have no
use-case for any of these other then where the guest can do nothing. I
also don't see what would be the usecase for the other two that would
warrant their addition over the mixed use that exists already.

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

My use-case is malware analysis. Any difference a malicious guest can
pick up about its host environment can be used to make a malware lie
dormant. Effectively it can aid the development of split-personality
malware that does one thing in a real environment while doing
something else when being analyzed.

Tamas

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