Mailing List Archive

[PATCH v3] Merge IS_PRIV checks into XSM hooks
Changes from v2:
* Added overall hooks for domctl, sysctl, and platform_hypercall so
that new sub-operations are protected by IS_PRIV checks
* Reorganized the IS_PRIV additions to dummy.h so they are added in the
same patch that removes the IS_PRIV they are replacing
* Reworked hooks in the MM hotpath to increase efficiency
* Dropped some unneeded XSM hook additions due to do_domctl hook
* Dropped the rcu_lock*target_domain_by_id function removal patch
* Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
* Use the existing hook function structure for tmem

Overall, this series should not change the behavior of Xen when XSM is
not enabled; however, in some cases, the exact errors that are returned
will be different because security checks have been moved below validity
checks.

Background:

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code.

When performing dom0 disaggregation, many of the functions normally
protected with IS_PRIV are handled by domains other than dom0. This
requires either making all such disaggregated domains privileged, or
allowing certain operations to be performed without an IS_PRIV check.
Because the privileged bit also short-circuits the IS_PRIV_FOR check,
and some IS_PRIV calls do not currently have an accompanying XSM call,
this series implements the second option.

Once applied, most IS_PRIV checks are isolated in the newly introduced
xen/include/xsm/dummy.h header. The remaining checks cover a few areas
that that have some reason to remain because they involve hardware
access or workarounds:

1. Overriding the IRQ and IO memory access checks (arch/x86/domctl.c).
These overrides should not be needed, as dom0 should have access
without needing the override.
2. Allow MAP_PIRQ_TYPE_GSI to ignore domain_pirq_to_irq negative return
3. The hack for device model framebuffers in get_page_from_l1e
4. Installing maps of non-owned pages in shadow_get_page_from_l1e
5. PCI configuration space (arch/x86/traps.c). Allowing a PV Linux domU
to access the PCI configuration space is a good way to crash the
system as it reconfigures PCI devices during boot, so this needs to
remain to get a working system when FLASK is in permissive mode.
6. Various MSR accesses (arch/x86/traps.c)

The ARM architecture is not touched at all in these patches; however,
none of the changes should affect ARM. XSM hooks will need to be added
for the arch-specific controls in order for FLASK to be useful on ARM,
but those changes are outside the scope of this series.

Miscellaneous updates to FLASK:
[PATCH 01/22] xsm/flask: remove inherited class attributes
[PATCH 02/22] xsm/flask: remove unneeded create_sid field
[PATCH 04/22] xsm/flask: add domain relabel support
[PATCH 05/22] libxl: introduce XSM relabel on build
[PATCH 06/22] flask/policy: Add domain relabel example
[PATCH 08/22] xsm/flask: Add checks on the domain performing the

Preparatory new functions/hooks:
[PATCH 03/22] xen: Add versions of rcu_lock_*_domain without IS_PRIV
[PATCH 07/22] arch/x86: add distinct XSM hooks for map/unmap
[PATCH 13/22] xen: lock target domain in do_domctl common code

IS_PRIV Refactoring:
[PATCH 09/22] xsm: Use the dummy XSM module if XSM is disabled
[PATCH 10/22] xen: use XSM instead of IS_PRIV where duplicated
[PATCH 11/22] xen: avoid calling rcu_lock_*target_domain when an XSM
[PATCH 12/22] arch/x86: convert platform_hypercall to use XSM
[PATCH 14/22] xen: convert do_domctl to use XSM
[PATCH 15/22] xen: convert do_sysctl to use XSM

Additional new/updated hooks:
[PATCH 16/22] xsm/flask: add missing hooks
[PATCH 17/22] xsm/flask: add distinct SIDs for self/target access
[PATCH 18/22] arch/x86: Add missing mem_sharing XSM hooks
[PATCH 19/22] arch/x86: check remote MMIO remap permissions
[PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner access checks
[PATCH 21/22] xen: Add XSM hook for XENMEM_exchange
[PATCH 22/22] tmem: add XSM hooks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [PATCH v3] Merge IS_PRIV checks into XSM hooks [ In reply to ]
Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> The ARM architecture is not touched at all in these patches; however,
> none of the changes should affect ARM. XSM hooks will need to be added
> for the arch-specific controls in order for FLASK to be useful on ARM,
> but those changes are outside the scope of this series.

By "not useful" I guess you mean that it wouldn't have the desired
security property. Is there already something that will prevent
attempts to use xsm on arm ? The code which enforces this should
ideally have a comment listing everything that was done to x86 but not
to arm, so that we have a useful todo list and don't miss anything
before enabling xsm on arm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [PATCH v3] Merge IS_PRIV checks into XSM hooks [ In reply to ]
On 09/13/2012 10:37 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
>> The ARM architecture is not touched at all in these patches; however,
>> none of the changes should affect ARM. XSM hooks will need to be added
>> for the arch-specific controls in order for FLASK to be useful on ARM,
>> but those changes are outside the scope of this series.
>
> By "not useful" I guess you mean that it wouldn't have the desired
> security property. Is there already something that will prevent
> attempts to use xsm on arm ? The code which enforces this should
> ideally have a comment listing everything that was done to x86 but not
> to arm, so that we have a useful todo list and don't miss anything
> before enabling xsm on arm.
>
> Ian.
>

Correct, XSM itself should work (i.e. boot and not crash) on ARM,
assuming there is support for loading a policy and the xsm_op hypercall
is wired up. The reason I noted that FLASK is not currently useful is
the lack of XSM hooks in various arch-specific functions (do_hvm_op and
arch_memory_op are the ones I have looked at). Adding these hooks
requires moving some of the definitions out of the #ifdef CONFIG_X86
blocks in the XSM code.

The ARM support in xen-unstable.h doesn't currently have any domctls or
sysctls defined; when it does, they will need to be added to the list of
hooks in flask_domctl/flask_sysctl with either an access check or a
pass-through due to the use of another hook. If not, they will trigger a
printk and be denied, so it's fairly easy to catch this.

Beyond the places where IS_PRIV is checked, FLASK hooks to control
access to hardware need to be added where there are ARM-specific
functions. For x86, this involved I/O ports, IRQ<->PIRQ mapping, and PCI
device access; some of these will apply to ARM if device passthrough is
supported there.

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [PATCH v3] Merge IS_PRIV checks into XSM hooks [ In reply to ]
Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> On 09/13/2012 10:37 AM, Ian Jackson wrote:
> The ARM support in xen-unstable.h doesn't currently have any domctls or
> sysctls defined; when it does, they will need to be added to the list of
> hooks in flask_domctl/flask_sysctl with either an access check or a
> pass-through due to the use of another hook. If not, they will trigger a
> printk and be denied, so it's fairly easy to catch this.

That last sentence is very reassuring to me. I was just wanting to
check that users weren't liable to try to use xsm and not notice that
it wasn't complete - and that when we did try to complete xsm on arm
we would avoid accidentally missing anything.

Thanks,
Ian.

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