|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |