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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Wed, Apr 5, 2017 at 9:04 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 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?

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

Sounds good to me.

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

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel