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

[Jan Beulich]

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

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

[George Dunlap]

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

[Tamas K Lengyel]

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 

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

[George Dunlap]

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 

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

[Jan Beulich]

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

[Jan Beulich]

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

[Daniel De Graaf]

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

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

[Tamas K Lengyel]

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