Re: [Xen-devel] XSM support for recently added priv hypercall ops

["George S. Coker, II" <george.coker@xxxxxxxxx>]

>
> when these hooks are enforced, do today's libraries and applications react
> approriately?
>
I believe yes, these hooks are in code paths where today IS_PRIV is
also checked
and may cause a return value of -EPERM or -ESRCH.  In my checking, few
of the libraries and
applications that I know about are sensitive to the exact value of the
return, but I understand that this isn't
always true.

> Would it not make sense to use the same hook for getting the cpu context and
> the extended cpu context?
>
I would like to distinguish the difference between the implementation
of a security module and the implementation of the framework.  The
framework defines distinct hooks for flexibility.  A security module
may instrument the same security function for all hooks because the
goals of the module are simple, e.g. is the caller privileged or not.
However, a security module may instrument distinct security functions
to meet finer grain goals.  One example could be to eliminate or limit
the use of particular code paths.  I would prefer that XSM not place
constraints on the goals of a security module.

For the get/set_vcpucontext and get/set_ext_vcpucontext hooks, the
get/set_vcpucontext hooks are in the common domctl code path and are
architecture neutral.  The get/set_ext_vcpucontext hooks are only
found, today, in the x86 code path.  Forcing the same hook assumes
something which isn't true, that all architectures are the same and
the impact of these operations are the same on all
architectures/platforms.

>    Stefan
>
> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 12/13/2007 01:43:16 PM:
>
>
>
>  > The attached patch provides an update to XSM and the associated
>  > security modules.  This patch enables
>  > XSM to interpose on the recently added privileged hypercall operations
>  > as well as refactors the existing
>  > IO assignment hooks.
>  >
>  > The patch applies cleanly against changeset 16606:8f0cbfc478d6.
>  >
>  > Signed-off by: George Coker <george.coker@xxxxxxxxx>,
> <gscoker@xxxxxxxxxxxxxx>
>  >
>  > XSM:
>  >
>  > The following hooks are added:
>  >     xsm_sendtrigger
>  >     xsm_test_assign_device
>  >     xsm_assign_device
>  >     xsm_bind_pt_irq
>  >     xsm_pin_mem_cacheattr
>  >     xsm_ext_vcpucontext
>  >     xsm_firmware_info
>  >     xsm_acpi_sleep
>  >     xsm_change_freq
>  >     xsm_getideltime
>  >     xsm_debug_keys
>  >     xsm_getcpuinfo
>  >     xsm_availheap
>  >     xsm_add_range
>  >     xsm_remove_range
>  >
>  > The following hooks are deprecated:
>  >     xsm_irq_permission
>  >     xsm_iomem_permission
>  >     xsm_ioport_permission
>  >
>  > The functionality provided by the deprecated hooks has been refactored
>  > into the xsm_add_range and
>  > xsm_remove_range hooks.  The refactoring enables XSM to centralize the
>  > interposition on IO resource
>  > assignment.  The refactoring was necessitated by the addition of the
>  > XEN_DOMCTL_memory_mapping
>  > and XEN_DOMCTL_ioport_mapping operations to support HVM domains.
>  >
>  > ACM:
>  >     - no updates to ACM
>  >
>  > FLASK:
>  >      - updated and refactored to implement the new XSM hooks
>  > [attachment "update-xsm-121307-xen-16606.diff" deleted by Stefan
>  > Berger/Watson/IBM] _______________________________________________
>  > Xen-devel mailing list
>  > Xen-devel@xxxxxxxxxxxxxxxxxxx
>  > http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel