[Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
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 Signed-off-by: Sergej Proskurin Acked-by: Wei Liu --- Cc: Ian Jackson Cc: Andrew Cooper Cc: Jan Beulich Cc: Daniel De Graaf 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 + +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. + +=back + =item B Enables or disables hvm guest access to alternate-p2m capability. @@ -1329,7 +1364,11 @@ 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 HVM domain memory introspection or for isolation/access-control of memory between components within -a single guest hvm domain. +a single guest hvm domain. This option is deprecated, use the option +"altp2m" instead. + +Note: While the option "altp2mhvm" is deprecated, legacy applications for +x86 systems will continue to work using it. =item B diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 399b91426b..bffbc456c1 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -902,14 +902,16 @@ static void initiate_domain_create(libxl__egc *egc, if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) && - libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) { +(libx
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
On 04/04/2017 11:24 AM, Tamas K Lengyel 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 Signed-off-by: Sergej Proskurin Acked-by: Wei Liu Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
>>> On 04.04.17 at 17:24, 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 > Signed-off-by: Sergej Proskurin > Acked-by: Wei Liu x86 hypervisor and public interface parts Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
>>> On 04.04.17 at 17:24, 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 > Signed-off-by: Sergej Proskurin > Acked-by: Wei Liu > --- > Cc: Ian Jackson > Cc: Andrew Cooper > Cc: Jan Beulich > Cc: Daniel De Graaf > > 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(-) George, strictly from the list of changed files your ack here is not required, but the subject made me want to at least ask whether you want to look over this, considering that you also weren't Cc-ed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
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 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 > Signed-off-by: Sergej Proskurin > Acked-by: Wei Liu > --- > Cc: Ian Jackson > Cc: Andrew Cooper > Cc: Jan Beulich > Cc: Daniel De Graaf > > 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 > + > +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
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
On Wed, Apr 5, 2017 at 9:04 AM, George Dunlap wrote: > On Tue, Apr 4, 2017 at 4:24 PM, Tamas K Lengyel > 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 >> Signed-off-by: Sergej Proskurin >> Acked-by: Wei Liu >> --- >> Cc: Ian Jackson >> Cc: Andrew Cooper >> Cc: Jan Beulich >> Cc: Daniel De Graaf >> >> 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 >> + >> +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? Yes. > 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
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
On 05/04/17 18:41, Tamas K Lengyel wrote: > On Wed, Apr 5, 2017 at 9:04 AM, George Dunlap > wrote: >> On Tue, Apr 4, 2017 at 4:24 PM, Tamas K Lengyel >> wrote: >> "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). [snip] >> Out of curiosity, what's the use case of the "mixed" mode? > > It's not entirely clear but that has been the mode that it was introduced > with. Actually I had some sort of a weird typo there... What I meant to ask about was actually "limited" mode: if the guest can't modify its own p2m tables, what's the use of a #VE? (Again, no objections to the patch, just curious.) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases
>>> On 06.04.17 at 10:52, wrote: > On 05/04/17 18:41, Tamas K Lengyel wrote: >> On Wed, Apr 5, 2017 at 9:04 AM, George Dunlap >> wrote: >>> On Tue, Apr 4, 2017 at 4:24 PM, Tamas K Lengyel >>> wrote: >>> "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). > [snip] >>> Out of curiosity, what's the use case of the "mixed" mode? >> >> It's not entirely clear but that has been the mode that it was introduced >> with. > > Actually I had some sort of a weird typo there... What I meant to ask > about was actually "limited" mode: if the guest can't modify its own p2m > tables, what's the use of a #VE? While this may not be as it works today, I'd expect "cannot change its altp2m-s" to neither imply in can't use VMFUNC to switch between them nor to extend to being able to set/clear the suppress-VE bit (which isn't permission bit after all). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel