Re: [Xen-devel] [PATCH v6] altp2m: Introduce external-only and limited use-cases

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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