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

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

On Mon, Apr 3, 2017 at 3:24 PM, Tamas K Lengyel
<tamas.lengyel@xxxxxxxxxxxx> wrote:
> On Tue, Mar 28, 2017 at 12:59 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> 
> 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 <tamas.lengyel@xxxxxxxxxxxx>
>>> Signed-off-by: Sergej Proskurin <proskurin@xxxxxxxxxxxxx>
>>
>>
>> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel