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