[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case
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. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |