Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

[Tamas K Lengyel]

On Mon, Apr 3, 2017 at 3:24 PM, Tamas K Lengyel
 wrote:
> On Tue, Mar 28, 2017 at 12:59 PM, Daniel De Graaf  
> wrote:
>> On 03/22/2017 02:07 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. 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 
>>
>>
>> I think the XSM-enabled case using the default types should have the same
>> flexibility as the XSM-disabled case.  I agree that it is useful to be able
>> to restrict the p2m features based on policy, and I don't think that it's
>> useful to expand the number of XSM permissions here.  In that case, the best
>> way to proceed would be to require that both the domain configuration and
>> XSM policy must allow the action (similar to how SELinux file controls and
>> UNIX permissions interact).  Currently, enabling XSM effectively forces the
>> value of this setting to "mixed", and "limited" is impossible to use with
>> XSM.
>
> I agree, however unfortunately due to the development effort to do
> that I will have to drop this patch. An earlier version only lacked
> the toolside ack so I thought it was about ready to go in. Hopefully
> one day in the future we will have XSM enabled by default and then we
> won't have to do things like this patch.
>

Daniel pointed out off-list that this can actually be achieved with a
minor adjustment in the flask function. I'll send v6 shortly.

Tamas

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

Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

[Tamas K Lengyel]

On Tue, Mar 28, 2017 at 12:59 PM, Daniel De Graaf  wrote:
> On 03/22/2017 02:07 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. 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 
>
>
> I think the XSM-enabled case using the default types should have the same
> flexibility as the XSM-disabled case.  I agree that it is useful to be able
> to restrict the p2m features based on policy, and I don't think that it's
> useful to expand the number of XSM permissions here.  In that case, the best
> way to proceed would be to require that both the domain configuration and
> XSM policy must allow the action (similar to how SELinux file controls and
> UNIX permissions interact).  Currently, enabling XSM effectively forces the
> value of this setting to "mixed", and "limited" is impossible to use with
> XSM.

I agree, however unfortunately due to the development effort to do
that I will have to drop this patch. An earlier version only lacked
the toolside ack so I thought it was about ready to go in. Hopefully
one day in the future we will have XSM enabled by default and then we
won't have to do things like this patch.

Tamas

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

Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

[Daniel De Graaf]

On 03/22/2017 02:07 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. 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 


I think the XSM-enabled case using the default types should have the same
flexibility as the XSM-disabled case.  I agree that it is useful to be able
to restrict the p2m features based on policy, and I don't think that it's
useful to expand the number of XSM permissions here.  In that case, the best
way to proceed would be to require that both the domain configuration and
XSM policy must allow the action (similar to how SELinux file controls and
UNIX permissions interact).  Currently, enabling XSM effectively forces the
value of this setting to "mixed", and "limited" is impossible to use with XSM.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

[Wei Liu]

On Wed, Mar 22, 2017 at 12:07:33PM -0600, 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. 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 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Andrew Cooper 
> Cc: Jan Beulich 
> Cc: Daniel De Graaf 
> 
> v4: Take patch out of ARM altp2m series. No hypervisor-side changes
> other then not touching ARM code anymore. Toolstack side introduces the
> altp2m config field such that it will require minimal churn once
> ARM altp2m is added.
> 
> v5: Add "limited" mode where the guest only has access to enable/disable
> VMFUNC and #VE features.
> ---
>  docs/man/xl.cfg.pod.5.in| 43 
> -
>  tools/libxl/libxl_create.c  |  6 --
>  tools/libxl/libxl_dom.c | 18 +++--
>  tools/libxl/libxl_types.idl | 14 ++
>  tools/xl/xl_parse.c | 20 ++-

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

[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. 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 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Daniel De Graaf 

v4: Take patch out of ARM altp2m series. No hypervisor-side changes
other then not touching ARM code anymore. Toolstack side introduces the
altp2m config field such that it will require minimal churn once
ARM altp2m is added.

v5: Add "limited" mode where the guest only has access to enable/disable
VMFUNC and #VE features.
---
 docs/man/xl.cfg.pod.5.in| 43 -
 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   |  2 +-
 10 files changed, 142 insertions(+), 24 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 52802d5d60..5349c642ba 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1283,6 +1283,43 @@ 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