[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
On Tue, Apr 4, 2017 at 4:24 PM, Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx> wrote: > Currently setting altp2mhvm=1 in the domain configuration allows access to the > altp2m interface for both in-guest and external privileged tools. This poses > a problem for use-cases where only external access should be allowed, > requiring > the user to compile Xen with XSM enabled to be able to appropriately restrict > access. > > In this patch we deprecate the altp2mhvm domain configuration option and > introduce the altp2m option, which allows specifying if by default the altp2m > interface should be external-only or limited. The information is stored in > HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes. > If external mode is selected, the XSM check is shifted to use XSM_DM_PRIV > type check, thus restricting access to the interface by the guest itself. Note > that we keep the default XSM policy untouched. Users of XSM who wish to > enforce > external mode for altp2m can do so by adjusting their XSM policy directly, > as this domain config option does not override an active XSM policy. > > Also, as part of this patch we adjust the hvmop handler to require > HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has > been > previously only required for get/set altp2m domain state, all other options > were gated on altp2m_enabled. Since altp2m_enabled only gets set during set > altp2m domain state, this change introduces no new requirements to the other > ops but makes it more clear that it is required for all ops. > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx> > Signed-off-by: Sergej Proskurin <proskurin@xxxxxxxxxxxxx> > Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> > --- > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Cc: Jan Beulich <jbeulich@xxxxxxxx> > Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> > > v5: Add "limited" mode where the guest only has access to enable/disable > VMFUNC and #VE features. > > v6: Check mode when XSM is enabled so that both the mode and the XSM policy > has to allow the altp2m operation to succeed. Makes limited mode available > even when XSM is enabled. > --- > docs/man/xl.cfg.pod.5.in | 41 > ++++++++++++++++++++++++++++++++++++++++- > tools/libxl/libxl_create.c | 6 ++++-- > tools/libxl/libxl_dom.c | 18 ++++++++++++++++-- > tools/libxl/libxl_types.idl | 14 ++++++++++++++ > tools/xl/xl_parse.c | 20 +++++++++++++++++++- > xen/arch/x86/hvm/hvm.c | 22 ++++++++++++---------- > xen/include/public/hvm/params.h | 12 +++++++++++- > xen/include/xsm/dummy.h | 23 ++++++++++++++++++++--- > xen/include/xsm/xsm.h | 6 +++--- > xen/xsm/flask/hooks.c | 21 ++++++++++++++++++++- > 10 files changed, 159 insertions(+), 24 deletions(-) > > diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in > index 206d33eb3f..616dc093b0 100644 > --- a/docs/man/xl.cfg.pod.5.in > +++ b/docs/man/xl.cfg.pod.5.in > @@ -1319,6 +1319,41 @@ enabled by default and you should usually omit it. It > may be necessary > to disable the HPET in order to improve compatibility with guest > Operating Systems (X86 only) > > +=item B<altp2m=MODE> > + > +Specifies access mode to the alternate-p2m capability. Alternate-p2m allows a > +guest to manage multiple p2m guest physical "memory views" (as opposed to a > +single p2m). This option is disabled by default and is available to x86 hvm > +domains. You may want this option if you want to access-control/isolate > +access to specific guest physical memory pages accessed by the guest, e.g. > for > +domain memory introspection or for isolation/access-control of memory between > +components within a single guest domain. > + > +The valid values are as follows: > + > +=over 4 > + > +=item B<"disabled"> > + > +Altp2m is disabled for the domain (default). > + > +=item B<"mixed"> > + > +The mixed mode allows access to the altp2m interface for both in-guest > +and external tools as well. > + > +=item B<"external"> > + > +Enables access to the alternate-p2m capability for hvm guests only > +by external privileged tools. > + > +=item B<"limited"> > + > +Enables limited access to the alternate-p2m capability for hvm guests only, > +ie. giving the guest access only to enable/disable the VMFUNC and #VE > features. So just trying to understand the options here... is it he case that in all non-"disabled" modes dom0 has access to all altp2m functionality? And so the various "enabled" modes are varying levels of access to guest functionality: - "external": No guest functionality - "limited": Guest can call HVMOP_altp2m_vcpu_enable_notify only - "mixed": Guest has access to all altp2m functionality If so, I think the documentation would be clearer like this: "mixed" Both external domains and the guest itself have full access to altp2m functionality "limited" External domains have access to full altp2m functionality; guest has access only to HVMOP_altp2m_vcpu_enable_notify (ability to enable VMFUNC and #VE features). "external" External domains have access to full altp2m functionality; guest has no access to any altp2m functionality. Out of curiosity, what's the use case of the "mixed" mode? Code itself looks good to me. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |