George S. Coker, II
2007-Dec-13 18:43 UTC
[Xen-devel] XSM support for recently added priv hypercall ops
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@gmail.com>,
<gscoker@alpha.ncsc.mil>
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Stefan Berger
2007-Dec-13 23:13 UTC
Re: [Xen-devel] XSM support for recently added priv hypercall ops
George, when these hooks are enforced, do today''s libraries and applications react approriately? Would it not make sense to use the same hook for getting the cpu context and the extended cpu context? Stefan xen-devel-bounces@lists.xensource.com 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@gmail.com>,<gscoker@alpha.ncsc.mil>> > 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2007-Dec-14 00:20 UTC
Re: [Xen-devel] XSM support for recently added priv hypercall ops
> > 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@lists.xensource.com 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@gmail.com>, > <gscoker@alpha.ncsc.mil> > > > > 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@lists.xensource.com > > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2007-Dec-17 22:00 UTC
Re: [Xen-devel] XSM support for recently added priv hypercall ops
On 12/13/07 7:20 PM, "George S. Coker, II" <george.coker@gmail.com> wrote:>> >> 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, In looking at the vcpucontext case again, it would be entirely reasonable to create a generic hook with an additional argument for the hypercall op. A module would then have the burden of checking the op for the architecture dependent ops. However, I dislike this approach because it obscures an arch dependency of the hook, something which has not been done for the other ops. I find the inconsistency problematic. Do you have a specific observation here, perhaps based on other architectures? George -- George S. Coker, II <gscoker@alpha.ncsc.mil> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan Berger
2007-Dec-17 23:58 UTC
Re: [Xen-devel] XSM support for recently added priv hypercall ops
"George S. Coker, II" <gscoker@alpha.ncsc.mil> wrote on 12/17/2007 05:00:39 PM:> > > > On 12/13/07 7:20 PM, "George S. Coker, II" <george.coker@gmail.com>wrote:> > >> > >> when these hooks are enforced, do today''s libraries and applicationsreact> >> 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, > > In looking at the vcpucontext case again, it would be entirelyreasonable to> create a generic hook with an additional argument for the hypercall op.A> module would then have the burden of checking the op for thearchitecture> dependent ops. However, I dislike this approach because it obscures anarch> dependency of the hook, something which has not been done for the otherops.> I find the inconsistency problematic. > > Do you have a specific observation here, perhaps based on other > architectures?Reading the extended vCPU context is part of suspend and migration operations, among a set of other hypercalls. Now these operations will fail if for example only reading the extended vCPU context is denied by a different hook than reading the ''normal'' vCPU context. Also the operations will fail depending on the processor type. I am afraid that none of this makes it easier to write a policy. Stefan> > George > > -- > George S. Coker, II <gscoker@alpha.ncsc.mil> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2007-Dec-19 23:22 UTC
Re: [Xen-devel] XSM support for recently added priv hypercall ops
On 12/17/07 6:58 PM, "Stefan Berger" <stefanb@us.ibm.com> wrote:> > "George S. Coker, II" <gscoker@alpha.ncsc.mil> wrote on 12/17/2007 05:00:39 > PM: > >> >> >> >> On 12/13/07 7:20 PM, "George S. Coker, II" <george.coker@gmail.com> wrote: >> >>>> >>>> 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, >> >> In looking at the vcpucontext case again, it would be entirely reasonable to >> create a generic hook with an additional argument for the hypercall op. A >> module would then have the burden of checking the op for the architecture >> dependent ops. However, I dislike this approach because it obscures an arch >> dependency of the hook, something which has not been done for the other ops. >> I find the inconsistency problematic. >> >> Do you have a specific observation here, perhaps based on other >> architectures? > > Reading the extended vCPU context is part of suspend and migration operations, > among a set of other hypercalls. Now these operations will fail if for example > only reading the extended vCPU context is denied by a different hook than > reading the ''normal'' vCPU context. Also the operations will fail depending on > the processor type. I am afraid that none of this makes it easier to write a > policy. >In looking into the issue further, it appears that the suspend code will silently take the security fault on get_ext_vcpucontext and manifest the fault as not implemented vice not permitted. This issue and others like it can be handled by a simple modification to libxc for more explicit error checking. Thanks for pointing this issue out. I''ll update my patches in the new year. While both get_ext_vcpucontext and get_vcpucontext are required for the correct operation of the suspend code, they are distinct code paths. XSM strives to be consistent with Xen by recognizing this distinction and not burying architectural assumptions in some parts of the framework while explicitly stating others. Although, I think the vcpucontext operations may be an exception since it is the only (off the top of my head) example of complementary functionality that spans arch and common trees. However, I would rather XSM not make this exception and remain consistent with Xen. In this case and others like it, XSM provides a given security module the flexibility to drop the arch and common distinction and marshal both code paths through a common security operation, but I don''t think the framework should make these kind of implementation choices especially since the framework has no impact on policy complexity. George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel