George S. Coker, II
2006-Sep-01 16:58 UTC
[Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
The attached patch implements the Xen Security Modules (XSM) framework. This patch should apply cleanly to changeset 9694:d82a4c4d04d4 Xen 3.0.2-3. The framework is configured as default-enable in this patch set. Configuration of XSM is made in Config.mk. The only configuration option is XSM_ENABLE = y/n. XSM_ENABLE must be y to compile an XSM module. XSM provides a generalized hook infrastructure allowing third-party security modules to interpose on the Xen code path. A default or dummy module provides basic call/return functionality for hooks not implemented by a given module. During module initialization, a module registers its security hooks and the equivalent dummy hooks are unregistered. If a module does not implement a hook, the equivalent dummy hook remains in place. Modules also may define and register at boot time a module specific hypercall through the XSM hook infrastructure. Modules may also define at Xen compile time a magic number XSM_MAGIC to indicate that a policy should be discovered from the images loaded at boot. The policy file should then be listed in grub as one of the multi-boot modules after the dom0 kernel. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Morris
2006-Sep-01 18:35 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 1 Sep 2006, George S. Coker, II wrote:> XSM provides a generalized hook infrastructure allowing third-party > security modules to interpose on the Xen code path. A default or dummy > module provides basic call/return functionality for hooks not > implemented by a given module.Do you have any performance figures for the dummy module? -- James Morris <jmorris@redhat.com> _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
George S. Coker, II
2006-Sep-01 18:47 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 2006-09-01 at 14:35 -0400, James Morris wrote:> On Fri, 1 Sep 2006, George S. Coker, II wrote: > > > XSM provides a generalized hook infrastructure allowing third-party > > security modules to interpose on the Xen code path. A default or dummy > > module provides basic call/return functionality for hooks not > > implemented by a given module. > > Do you have any performance figures for the dummy module? > >No, we do not at this time. Our only performance metric is observation which isn''t prompting us to look further at the moment. However, this is a fair question to ask. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Chris Wright
2006-Sep-01 18:55 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
* George S. Coker, II (gscoker@alpha.ncsc.mil) wrote:> The attached patch implements the Xen Security Modules (XSM) framework. > This patch should apply cleanly to changeset 9694:d82a4c4d04d4 Xen > 3.0.2-3.Nice to see this all posted. Have any perfomance numbers for default dummy, or numbers for increase in memory footprint for this + flask + flask example policy? Just curious to see what the rough cost is. Some quick comments below.> Modules may also define at Xen compile time a magic number XSM_MAGIC to > indicate that a policy should be discovered from the images loaded at > boot. The policy file should then be listed in grub as one of the > multi-boot modules after the dom0 kernel.I like that feature.> diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/dom0_ops.c > --- a/xen/arch/x86/dom0_ops.c Fri May 26 09:23:33 2006 +0100 > +++ b/xen/arch/x86/dom0_ops.c Thu Aug 31 17:14:49 2006 -0400 > @@ -25,6 +25,7 @@ > #include <asm/hvm/support.h> > #include <asm/processor.h> > #include <public/sched_ctl.h> > +#include <xsm/xsm.h> > > #include <asm/mtrr.h> > #include "cpu/mtrr/mtrr.h" > @@ -58,6 +59,10 @@ long arch_do_dom0_op(struct dom0_op *op, > > case DOM0_MSR: > { > + ret = xsm_msr(op->u.msr.write);Hmm, this is against 3.0.2, unfortunately you''ll have some work to move to 3.0.3 with the hypercall changes here (IIRC, this one actually went away). And have you done each arch? I only see x86 here. <snip>> diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/setup.c > --- a/xen/arch/x86/setup.c Fri May 26 09:23:33 2006 +0100 > +++ b/xen/arch/x86/setup.c Thu Aug 31 17:14:49 2006 -0400 > @@ -24,6 +24,7 @@ > #include <asm/shadow.h> > #include <asm/e820.h> > #include <acm/acm_hooks.h> > +#include <xsm/xsm.h> > > extern void dmi_scan_machine(void); > extern void generic_apic_probe(void); > @@ -404,6 +405,8 @@ void __init __start_xen(multiboot_info_t > > scheduler_init(); > > + xsm_init(&initrdidx, mbi, initial_images_start); > + > idle_domain = domain_create(IDLE_DOMAIN_ID, 0); > BUG_ON(idle_domain == NULL); > > @@ -507,6 +510,8 @@ void __init __start_xen(multiboot_info_t > set_bit(_DOMF_privileged, &dom0->domain_flags); > /* post-create hooks sets security label */ > acm_post_domain0_create(dom0->domain_id); > + > + xsm_complete_init(dom0);Seems this should drop the acm hook here, no?> /* Grab the DOM0 command line. */ > cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL); > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/x86_32/entry.S > --- a/xen/arch/x86/x86_32/entry.S Fri May 26 09:23:33 2006 +0100 > +++ b/xen/arch/x86/x86_32/entry.S Thu Aug 31 17:14:49 2006 -0400 > @@ -648,6 +648,7 @@ ENTRY(hypercall_table) > .long do_acm_op > .long do_nmi_op > .long do_arch_sched_op > + .long do_xsm_op /* 30 */ > .rept NR_hypercalls-((.-hypercall_table)/4) > .long do_ni_hypercall > .endr > @@ -683,6 +684,7 @@ ENTRY(hypercall_args_table) > .byte 1 /* do_acm_op */ > .byte 2 /* do_nmi_op */ > .byte 2 /* do_arch_sched_op */ > + .byte 1 /* do_xsm_op */ > .rept NR_hypercalls-(.-hypercall_args_table) > .byte 0 /* do_ni_hypercall */ > .endr > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/x86_32/xen.lds.S > --- a/xen/arch/x86/x86_32/xen.lds.S Fri May 26 09:23:33 2006 +0100 > +++ b/xen/arch/x86/x86_32/xen.lds.S Thu Aug 31 17:14:49 2006 -0400 > @@ -56,6 +56,7 @@ SECTIONS > __initcall_start = .; > .initcall.init : { *(.initcall.init) } :text > __initcall_end = .; > + .xsm_initcall.init : { __xsm_initcall_start = .; *(.xsm_initcall.init) __xsm_initcall_end = .; } > . = ALIGN(STACK_SIZE); > __init_end = .; > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/common/dom0_ops.c > --- a/xen/common/dom0_ops.c Fri May 26 09:23:33 2006 +0100 > +++ b/xen/common/dom0_ops.c Thu Aug 31 17:14:49 2006 -0400 > @@ -22,6 +22,7 @@ > #include <public/dom0_ops.h> > #include <public/sched_ctl.h> > #include <acm/acm_hooks.h> > +#include <xsm/xsm.h> > > extern long arch_do_dom0_op( > struct dom0_op *op, GUEST_HANDLE(dom0_op_t) u_dom0_op); > @@ -82,6 +83,8 @@ static void getdomaininfo(struct domain > info->ssidref = ((struct acm_ssid_domain *)d->ssid)->ssidref; > else > info->ssidref = ACM_DEFAULT_SSID; > + > + xsm_security_domaininfo(d, info); > > info->tot_pages = d->tot_pages; > info->max_pages = d->max_pages; > @@ -120,7 +123,12 @@ long do_dom0_op(GUEST_HANDLE(dom0_op_t)shouldn''t this take care of the acm_pre_dom0_op hook here as well? IOW, at the end there shouldn''t be acm specific hooks left, right?> diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/common/domain.c > --- a/xen/common/domain.c Fri May 26 09:23:33 2006 +0100 > +++ b/xen/common/domain.c Thu Aug 31 17:14:49 2006 -0400 > @@ -24,6 +24,7 @@ > #include <public/dom0_ops.h> > #include <public/sched.h> > #include <public/vcpu.h> > +#include <xsm/xsm.h> > > /* Both these structures are protected by the domlist_lock. */ > rwlock_t domlist_lock = RW_LOCK_UNLOCKED; > @@ -50,6 +51,9 @@ struct domain *domain_create(domid_t dom > INIT_LIST_HEAD(&d->xenpage_list); > > rangeset_domain_initialise(d); > + > + if (xsm_alloc_security_domain(d)) > + goto fail1; > > if ( !is_idle_domain(d) ) > { > @@ -305,6 +309,8 @@ void domain_destroy(struct domain *d) > > arch_domain_destroy(d); > > + xsm_free_security_domain(d); > + > free_domain(d); > > send_guest_virq(dom0->vcpu[0], VIRQ_DOM_EXC); > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/grant_table.h > --- a/xen/include/xen/grant_table.h Fri May 26 09:23:33 2006 +0100 > +++ b/xen/include/xen/grant_table.h Thu Aug 31 17:14:49 2006 -0400 > @@ -74,6 +74,7 @@ typedef struct { > grant_entry_t *shared; > /* Active grant table. */ > active_grant_entry_t *active; > + void *security;What''s a grant table label look like?> /* Mapping tracking table. */ > grant_mapping_t *maptrack; > unsigned int maptrack_head; > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/hypercall.h > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/sched.h > --- a/xen/include/xen/sched.h Fri May 26 09:23:33 2006 +0100 > +++ b/xen/include/xen/sched.h Thu Aug 31 17:14:49 2006 -0400 > @@ -47,6 +47,7 @@ struct evtchn > u16 pirq; /* state == ECS_PIRQ */ > u16 virq; /* state == ECS_VIRQ */ > } u; > + void *ssid; > };Ah, you must resue the acm domain label? Actually would be nice to see which objects are labelled, did I miss that list?> int evtchn_init(struct domain *d); > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xsm/xsm.h > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > +++ b/xen/include/xsm/xsm.h Thu Aug 31 17:14:49 2006 -0400 > @@ -0,0 +1,722 @@ > +/* > + * This file contains the Flask hook function implementations for Xen. > + * > + * This work is based on the LSM implementation in Linux 2.6.13.4. > + * > + * Author: George Coker, <gscoker@alpha.ncsc.mil> > + * > + * Contributors: Michael LeMay, <mdlemay@epoch.ncsc.mil> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2, > + * as published by the Free Software Foundation. > + */ > + > +#ifndef __XSM_H__ > +#define __XSM_H__ > + > +#include <xen/sched.h> > +#include <xen/multiboot.h> > + > +#ifdef XSM_ENABLE > + > +/* policy magic number (defined by XSM_MAGIC) */ > +typedef u32 xsm_magic_t; > +#ifndef XSM_MAGIC > +#define XSM_MAGIC 0x00000000 > +#endif > + > +extern char *policy_buffer; > +extern u32 policy_size; > + > +typedef void xsm_op_t; > +DEFINE_GUEST_HANDLE(xsm_op_t); > + > +typedef int (*xsm_initcall_t)(void); > + > +extern xsm_initcall_t __xsm_initcall_start[], __xsm_initcall_end[]; > + > +#define xsm_initcall(fn) \ > + static xsm_initcall_t __initcall_##fn \ > + __attribute_used__ __attribute__((__section__(".xsm_initcall.init"))) = fn > + > +struct xsm_operations { > + void (*security_domaininfo) (struct domain *d, dom0_getdomaininfo_t *info); > + int (*setvcpucontext) (struct domain *d); > + int (*pausedomain) (struct domain *d); > + int (*unpausedomain) (struct domain *d); > + int (*createdomain) (dom0_op_t *op); > + void (*createdomain_post) (struct domain *d, dom0_op_t *op); > + void (*createdomain_fail) (dom0_op_t *op); > + int (*max_vcpus) (struct domain *d); > + int (*destroydomain) (struct domain *d); > + int (*setvcpuaffinity) (struct domain *d); > + int (*schedctl) (struct sched_ctl_cmd *cmd); > + int (*adjustdom) (struct sched_adjdom_cmd *cmd); > + int (*getdomaininfo) (struct domain *d); > + int (*getvcpucontext) (struct domain *d); > + int (*getvcpuinfo) (struct domain *d); > + int (*settime) (void); > + int (*tbufcontrol) (void); > + int (*readconsole) (uint32_t clear); > + int (*sched_id) (void); > + int (*setdomainmaxmem) (struct domain *d); > + int (*setdomainhandle) (struct domain *d); > + int (*setdebugging) (struct domain *d); > + int (*irq_permission) (struct domain *d, uint8_t pirq, uint8_t access); > + int (*iomem_permission) (struct domain *d, unsigned long mfn, uint8_t access); > + int (*perfcontrol) (void); > + > + int (*msr) (uint32_t);Platform specific code might want ifdefs, or perhaps a just platform specific set of ops.> + int (*shadow_control) (struct domain *d, uint32_t op); > + int (*memtype) (uint32_t access); > + int (*microcode) (void); > + int (*ioport_permission) (struct domain *d, uint32_t ioport, uint8_t access); > + int (*physinfo) (void); > + int (*getpageframeinfo) (unsigned long mfn); > + int (*getmemlist) (struct domain *d); > + int (*platform_quirk) (uint32_t); > + int (*physmemmap) (void); > + int (*hypercall_init) (struct domain *d); > + > + int (*evtchn_unbound) (struct domain *d, struct evtchn *chn, domid_t id2); > + int (*evtchn_interdomain) (struct domain *d1, struct evtchn *chn1, > + struct domain *d2, struct evtchn *chn2); > + int (*evtchn_virq) (struct domain *d, struct evtchn *chn, int virq, int vcpu); > + int (*evtchn_ipi) (struct domain *d, struct evtchn *chn, int vcpu); > + int (*evtchn_pirq) (struct domain *d, struct evtchn *chn, int pirq); > + int (*evtchn_close) (struct domain *d, struct evtchn *chn); > + int (*evtchn_send) (struct domain *d, struct evtchn *chn); > + int (*evtchn_status) (struct domain *d, struct evtchn *chn); > + int (*evtchn_vcpu) (struct domain *d, struct evtchn *chn, unsigned int vcpu); > + int (*evtchn_unmask) (struct domain *d, struct evtchn *chn); > + int (*evtchn_init) (struct domain *d, struct evtchn *chn); > + > + int (*grant_mapref) (struct domain *d1, struct domain *d2, uint32_t flags); > + int (*grant_unmapref) (struct domain *d1, struct domain *d2); > + int (*grant_setup) (struct domain *d1, struct domain *d2); > + int (*grant_transfer) (struct domain *d1, struct domain *d2); > + > + int (*alloc_security_domain) (struct domain *d); > + void (*free_security_domain) (struct domain *d); > + int (*alloc_security_evtchn) (struct evtchn *chn); > + void (*free_security_evtchn) (struct evtchn *chn);Heh, well, that''s as good as a list ;-)> + int (*mmu_normal_update) (struct domain *d, intpte_t fpte); > + > + long (*__do_xsm_op) (GUEST_HANDLE(xsm_op_t) op);We very intentionally did not do this in LSM (or more to the point, we did and it was soundly rejected). It''s a free form way to extend the hypercall interface, which in Linux is frowned upon. Of course, you don''t have the various selinuxfs, /proc/<pid>/attr type of interfaces in the hypervisor, but it''s worth considering if there are other possibilities (32/64-bit compat is an example of something which is easily lost when pushing the hypercall interface down a layer into the module).> diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/Makefile > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > +++ b/xen/xsm/Makefile Thu Aug 31 17:14:49 2006 -0400 > @@ -0,0 +1,3 @@ > +obj-y += xsm_core.o > +obj-y += xsm_policy.o > +obj-y += dummy.o > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/dummy.c > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > +++ b/xen/xsm/dummy.c Thu Aug 31 17:14:49 2006 -0400 > @@ -0,0 +1,392 @@ > +#include <xen/sched.h> > +#include <xsm/xsm.h> > + > +#ifdef XSM_ENABLECan you just conditionally compile in this file using the above Makefile?> diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/xsm_core.c > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > +++ b/xen/xsm/xsm_core.c Thu Aug 31 17:14:49 2006 -0400<snip>> +#ifdef XSM_ENABLE > +#endif > + > +long do_xsm_op (GUEST_HANDLE(xsm_op_t) op) > +{ > + return __do_xsm_op(op); > +}Linux has the cond_syscall() macro, should be enough to do this if you can''t find a better way to do security module specifc calls. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Chris Wright
2006-Sep-01 19:00 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
* Chris Wright (chrisw@sous-sol.org) wrote:> > --- a/xen/arch/x86/x86_32/entry.S Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/arch/x86/x86_32/entry.S Thu Aug 31 17:14:49 2006 -0400 > > @@ -648,6 +648,7 @@ ENTRY(hypercall_table) > > .long do_acm_op > > .long do_nmi_op > > .long do_arch_sched_op > > + .long do_xsm_op /* 30 */And I forgot to ask, do you change the acm_op entrypoints to go through this callback? thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2006-Sep-01 19:37 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 2006-09-01 at 11:55 -0700, Chris Wright wrote:> * George S. Coker, II (gscoker@alpha.ncsc.mil) wrote: > > The attached patch implements the Xen Security Modules (XSM) framework. > > This patch should apply cleanly to changeset 9694:d82a4c4d04d4 Xen > > 3.0.2-3. > > Nice to see this all posted. Have any perfomance numbers for default > dummy, or numbers for increase in memory footprint for this + flask + > flask example policy? Just curious to see what the rough cost is. > Some quick comments below. > > > Modules may also define at Xen compile time a magic number XSM_MAGIC to > > indicate that a policy should be discovered from the images loaded at > > boot. The policy file should then be listed in grub as one of the > > multi-boot modules after the dom0 kernel. > > I like that feature. > > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/dom0_ops.c > > --- a/xen/arch/x86/dom0_ops.c Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/arch/x86/dom0_ops.c Thu Aug 31 17:14:49 2006 -0400 > > @@ -25,6 +25,7 @@ > > #include <asm/hvm/support.h> > > #include <asm/processor.h> > > #include <public/sched_ctl.h> > > +#include <xsm/xsm.h> > > > > #include <asm/mtrr.h> > > #include "cpu/mtrr/mtrr.h" > > @@ -58,6 +59,10 @@ long arch_do_dom0_op(struct dom0_op *op, > > > > case DOM0_MSR: > > { > > + ret = xsm_msr(op->u.msr.write); > > Hmm, this is against 3.0.2, unfortunately you''ll have some work to move > to 3.0.3 with the hypercall changes here (IIRC, this one actually > went away). And have you done each arch? I only see x86 here. >We have only done x86 for now.> <snip> > > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/setup.c > > --- a/xen/arch/x86/setup.c Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/arch/x86/setup.c Thu Aug 31 17:14:49 2006 -0400 > > @@ -24,6 +24,7 @@ > > #include <asm/shadow.h> > > #include <asm/e820.h> > > #include <acm/acm_hooks.h> > > +#include <xsm/xsm.h> > > > > extern void dmi_scan_machine(void); > > extern void generic_apic_probe(void); > > @@ -404,6 +405,8 @@ void __init __start_xen(multiboot_info_t > > > > scheduler_init(); > > > > + xsm_init(&initrdidx, mbi, initial_images_start); > > + > > idle_domain = domain_create(IDLE_DOMAIN_ID, 0); > > BUG_ON(idle_domain == NULL); > > > > @@ -507,6 +510,8 @@ void __init __start_xen(multiboot_info_t > > set_bit(_DOMF_privileged, &dom0->domain_flags); > > /* post-create hooks sets security label */ > > acm_post_domain0_create(dom0->domain_id); > > + > > + xsm_complete_init(dom0); > > Seems this should drop the acm hook here, no? >We did not want the XSM patch to add XSM and remove ACM because we do not believe that the community sees ACM and sHype as the distinct entities that they really are. That''s why we have the patch that removes the duplicated hooks and code and produces a module called ACM. Hopefully in the future XSM will refer to the security framework and the the STE/Chinese Wall functionality of ACM will be called the sHype module.> > /* Grab the DOM0 command line. */ > > cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL); > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/x86_32/entry.S > > --- a/xen/arch/x86/x86_32/entry.S Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/arch/x86/x86_32/entry.S Thu Aug 31 17:14:49 2006 -0400 > > @@ -648,6 +648,7 @@ ENTRY(hypercall_table) > > .long do_acm_op > > .long do_nmi_op > > .long do_arch_sched_op > > + .long do_xsm_op /* 30 */ > > .rept NR_hypercalls-((.-hypercall_table)/4) > > .long do_ni_hypercall > > .endr > > @@ -683,6 +684,7 @@ ENTRY(hypercall_args_table) > > .byte 1 /* do_acm_op */ > > .byte 2 /* do_nmi_op */ > > .byte 2 /* do_arch_sched_op */ > > + .byte 1 /* do_xsm_op */ > > .rept NR_hypercalls-(.-hypercall_args_table) > > .byte 0 /* do_ni_hypercall */ > > .endr > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/arch/x86/x86_32/xen.lds.S > > --- a/xen/arch/x86/x86_32/xen.lds.S Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/arch/x86/x86_32/xen.lds.S Thu Aug 31 17:14:49 2006 -0400 > > @@ -56,6 +56,7 @@ SECTIONS > > __initcall_start = .; > > .initcall.init : { *(.initcall.init) } :text > > __initcall_end = .; > > + .xsm_initcall.init : { __xsm_initcall_start = .; *(.xsm_initcall.init) __xsm_initcall_end = .; } > > . = ALIGN(STACK_SIZE); > > __init_end = .; > > > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/common/dom0_ops.c > > --- a/xen/common/dom0_ops.c Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/common/dom0_ops.c Thu Aug 31 17:14:49 2006 -0400 > > @@ -22,6 +22,7 @@ > > #include <public/dom0_ops.h> > > #include <public/sched_ctl.h> > > #include <acm/acm_hooks.h> > > +#include <xsm/xsm.h> > > > > extern long arch_do_dom0_op( > > struct dom0_op *op, GUEST_HANDLE(dom0_op_t) u_dom0_op); > > @@ -82,6 +83,8 @@ static void getdomaininfo(struct domain > > info->ssidref = ((struct acm_ssid_domain *)d->ssid)->ssidref; > > else > > info->ssidref = ACM_DEFAULT_SSID; > > + > > + xsm_security_domaininfo(d, info); > > > > info->tot_pages = d->tot_pages; > > info->max_pages = d->max_pages; > > @@ -120,7 +123,12 @@ long do_dom0_op(GUEST_HANDLE(dom0_op_t) > > shouldn''t this take care of the acm_pre_dom0_op hook here as well? > IOW, at the end there shouldn''t be acm specific hooks left, right? > > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/common/domain.c > > --- a/xen/common/domain.c Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/common/domain.c Thu Aug 31 17:14:49 2006 -0400 > > @@ -24,6 +24,7 @@ > > #include <public/dom0_ops.h> > > #include <public/sched.h> > > #include <public/vcpu.h> > > +#include <xsm/xsm.h> > > > > /* Both these structures are protected by the domlist_lock. */ > > rwlock_t domlist_lock = RW_LOCK_UNLOCKED; > > @@ -50,6 +51,9 @@ struct domain *domain_create(domid_t dom > > INIT_LIST_HEAD(&d->xenpage_list); > > > > rangeset_domain_initialise(d); > > + > > + if (xsm_alloc_security_domain(d)) > > + goto fail1; > > > > if ( !is_idle_domain(d) ) > > { > > @@ -305,6 +309,8 @@ void domain_destroy(struct domain *d) > > > > arch_domain_destroy(d); > > > > + xsm_free_security_domain(d); > > + > > free_domain(d); > > > > send_guest_virq(dom0->vcpu[0], VIRQ_DOM_EXC); > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/grant_table.h > > --- a/xen/include/xen/grant_table.h Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/include/xen/grant_table.h Thu Aug 31 17:14:49 2006 -0400 > > @@ -74,6 +74,7 @@ typedef struct { > > grant_entry_t *shared; > > /* Active grant table. */ > > active_grant_entry_t *active; > > + void *security; > > What''s a grant table label look like?This is detritus in the patch. We have chosen not to put security structures in grant tables at this time. We were looking into it, but because the guest has complete control over the contents of the grant entry, i.e. which page, there is no benefit than to check the permissions on the domains involved in the grant.> > > /* Mapping tracking table. */ > > grant_mapping_t *maptrack; > > unsigned int maptrack_head; > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/hypercall.h > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xen/sched.h > > --- a/xen/include/xen/sched.h Fri May 26 09:23:33 2006 +0100 > > +++ b/xen/include/xen/sched.h Thu Aug 31 17:14:49 2006 -0400 > > @@ -47,6 +47,7 @@ struct evtchn > > u16 pirq; /* state == ECS_PIRQ */ > > u16 virq; /* state == ECS_VIRQ */ > > } u; > > + void *ssid; > > }; > > Ah, you must resue the acm domain label? Actually would be nice to see > which objects are labelled, did I miss that list? >We presently have security labels on domains and event channels. We reuse the security pointer added by ACM for domains. We do not have labels on other hypervisor objects. The Flask module does use the policy infrastructure to lookup labels on platform resources such as physical interrupts.> > int evtchn_init(struct domain *d); > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/include/xsm/xsm.h > > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > > +++ b/xen/include/xsm/xsm.h Thu Aug 31 17:14:49 2006 -0400 > > @@ -0,0 +1,722 @@ > > +/* > > + * This file contains the Flask hook function implementations for Xen. > > + * > > + * This work is based on the LSM implementation in Linux 2.6.13.4. > > + * > > + * Author: George Coker, <gscoker@alpha.ncsc.mil> > > + * > > + * Contributors: Michael LeMay, <mdlemay@epoch.ncsc.mil> > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2, > > + * as published by the Free Software Foundation. > > + */ > > + > > +#ifndef __XSM_H__ > > +#define __XSM_H__ > > + > > +#include <xen/sched.h> > > +#include <xen/multiboot.h> > > + > > +#ifdef XSM_ENABLE > > + > > +/* policy magic number (defined by XSM_MAGIC) */ > > +typedef u32 xsm_magic_t; > > +#ifndef XSM_MAGIC > > +#define XSM_MAGIC 0x00000000 > > +#endif > > + > > +extern char *policy_buffer; > > +extern u32 policy_size; > > + > > +typedef void xsm_op_t; > > +DEFINE_GUEST_HANDLE(xsm_op_t); > > + > > +typedef int (*xsm_initcall_t)(void); > > + > > +extern xsm_initcall_t __xsm_initcall_start[], __xsm_initcall_end[]; > > + > > +#define xsm_initcall(fn) \ > > + static xsm_initcall_t __initcall_##fn \ > > + __attribute_used__ __attribute__((__section__(".xsm_initcall.init"))) = fn > > + > > +struct xsm_operations { > > + void (*security_domaininfo) (struct domain *d, dom0_getdomaininfo_t *info); > > + int (*setvcpucontext) (struct domain *d); > > + int (*pausedomain) (struct domain *d); > > + int (*unpausedomain) (struct domain *d); > > + int (*createdomain) (dom0_op_t *op); > > + void (*createdomain_post) (struct domain *d, dom0_op_t *op); > > + void (*createdomain_fail) (dom0_op_t *op); > > + int (*max_vcpus) (struct domain *d); > > + int (*destroydomain) (struct domain *d); > > + int (*setvcpuaffinity) (struct domain *d); > > + int (*schedctl) (struct sched_ctl_cmd *cmd); > > + int (*adjustdom) (struct sched_adjdom_cmd *cmd); > > + int (*getdomaininfo) (struct domain *d); > > + int (*getvcpucontext) (struct domain *d); > > + int (*getvcpuinfo) (struct domain *d); > > + int (*settime) (void); > > + int (*tbufcontrol) (void); > > + int (*readconsole) (uint32_t clear); > > + int (*sched_id) (void); > > + int (*setdomainmaxmem) (struct domain *d); > > + int (*setdomainhandle) (struct domain *d); > > + int (*setdebugging) (struct domain *d); > > + int (*irq_permission) (struct domain *d, uint8_t pirq, uint8_t access); > > + int (*iomem_permission) (struct domain *d, unsigned long mfn, uint8_t access); > > + int (*perfcontrol) (void); > > + > > + int (*msr) (uint32_t); > > Platform specific code might want ifdefs, or perhaps a just platform > specific set of ops.Right, because we are x86 specific at this time. But we should be more careful.> > > + int (*shadow_control) (struct domain *d, uint32_t op); > > + int (*memtype) (uint32_t access); > > + int (*microcode) (void); > > + int (*ioport_permission) (struct domain *d, uint32_t ioport, uint8_t access); > > + int (*physinfo) (void); > > + int (*getpageframeinfo) (unsigned long mfn); > > + int (*getmemlist) (struct domain *d); > > + int (*platform_quirk) (uint32_t); > > + int (*physmemmap) (void); > > + int (*hypercall_init) (struct domain *d); > > + > > + int (*evtchn_unbound) (struct domain *d, struct evtchn *chn, domid_t id2); > > + int (*evtchn_interdomain) (struct domain *d1, struct evtchn *chn1, > > + struct domain *d2, struct evtchn *chn2); > > + int (*evtchn_virq) (struct domain *d, struct evtchn *chn, int virq, int vcpu); > > + int (*evtchn_ipi) (struct domain *d, struct evtchn *chn, int vcpu); > > + int (*evtchn_pirq) (struct domain *d, struct evtchn *chn, int pirq); > > + int (*evtchn_close) (struct domain *d, struct evtchn *chn); > > + int (*evtchn_send) (struct domain *d, struct evtchn *chn); > > + int (*evtchn_status) (struct domain *d, struct evtchn *chn); > > + int (*evtchn_vcpu) (struct domain *d, struct evtchn *chn, unsigned int vcpu); > > + int (*evtchn_unmask) (struct domain *d, struct evtchn *chn); > > + int (*evtchn_init) (struct domain *d, struct evtchn *chn); > > + > > + int (*grant_mapref) (struct domain *d1, struct domain *d2, uint32_t flags); > > + int (*grant_unmapref) (struct domain *d1, struct domain *d2); > > + int (*grant_setup) (struct domain *d1, struct domain *d2); > > + int (*grant_transfer) (struct domain *d1, struct domain *d2); > > + > > + int (*alloc_security_domain) (struct domain *d); > > + void (*free_security_domain) (struct domain *d); > > + int (*alloc_security_evtchn) (struct evtchn *chn); > > + void (*free_security_evtchn) (struct evtchn *chn); > > Heh, well, that''s as good as a list ;-) > > > + int (*mmu_normal_update) (struct domain *d, intpte_t fpte); > > + > > + long (*__do_xsm_op) (GUEST_HANDLE(xsm_op_t) op); > > We very intentionally did not do this in LSM (or more to the point, > we did and it was soundly rejected). It''s a free form way to extend the > hypercall interface, which in Linux is frowned upon. Of course, you don''t > have the various selinuxfs, /proc/<pid>/attr type of interfaces in the > hypervisor, but it''s worth considering if there are other possibilities > (32/64-bit compat is an example of something which is easily lost when > pushing the hypercall interface down a layer into the module). > > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/Makefile > > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > > +++ b/xen/xsm/Makefile Thu Aug 31 17:14:49 2006 -0400 > > @@ -0,0 +1,3 @@ > > +obj-y += xsm_core.o > > +obj-y += xsm_policy.o > > +obj-y += dummy.o > > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/dummy.c > > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > > +++ b/xen/xsm/dummy.c Thu Aug 31 17:14:49 2006 -0400 > > @@ -0,0 +1,392 @@ > > +#include <xen/sched.h> > > +#include <xsm/xsm.h> > > + > > +#ifdef XSM_ENABLE > > Can you just conditionally compile in this file using the above Makefile? >yes.> > diff -r d82a4c4d04d4 -r a24b5a5f5f5b xen/xsm/xsm_core.c > > --- /dev/null Thu Jan 1 00:00:00 1970 +0000 > > +++ b/xen/xsm/xsm_core.c Thu Aug 31 17:14:49 2006 -0400 > <snip> > > +#ifdef XSM_ENABLE > > +#endif > > + > > +long do_xsm_op (GUEST_HANDLE(xsm_op_t) op) > > +{ > > + return __do_xsm_op(op); > > +} > > Linux has the cond_syscall() macro, should be enough to do this > if you can''t find a better way to do security module specifc > calls. >-- George S. Coker, II <gscoker@alpha.ncsc.mil> 443-479-6944 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George S. Coker, II
2006-Sep-01 19:39 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 2006-09-01 at 12:00 -0700, Chris Wright wrote:> * Chris Wright (chrisw@sous-sol.org) wrote: > > > --- a/xen/arch/x86/x86_32/entry.S Fri May 26 09:23:33 2006 +0100 > > > +++ b/xen/arch/x86/x86_32/entry.S Thu Aug 31 17:14:49 2006 -0400 > > > @@ -648,6 +648,7 @@ ENTRY(hypercall_table) > > > .long do_acm_op > > > .long do_nmi_op > > > .long do_arch_sched_op > > > + .long do_xsm_op /* 30 */ > > And I forgot to ask, do you change the acm_op entrypoints to > go through this callback? >In the ACM patch, the only entrypoint to acp_op is through xsm_op.> thanks, > -chris-- George S. Coker, II <gscoker@alpha.ncsc.mil> 443-479-6944 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Morris
2006-Sep-01 19:46 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Fri, 1 Sep 2006, Chris Wright wrote:> > + int (*mmu_normal_update) (struct domain *d, intpte_t fpte); > > + > > + long (*__do_xsm_op) (GUEST_HANDLE(xsm_op_t) op); > > We very intentionally did not do this in LSM (or more to the point, > we did and it was soundly rejected). It''s a free form way to extend the > hypercall interface, which in Linux is frowned upon.I agree with Chris here -- it''s definitely an architectural issue to consider, in that you can end up with an arbitrary interface with weak semantics, which is prone to maintainability & security issues, tasteless abuse by third party code etc.> Of course, you don''t have the various selinuxfs, /proc/<pid>/attr type > of interfaces in the hypervisor, but it''s worth considering if there are > other possibilities (32/64-bit compat is an example of something which > is easily lost when pushing the hypercall interface down a layer into > the module).One interface possibility is some kind of extensible message passing channel (perhaps like Netlink). George, what did you have in mind as use-cases for this op? - James -- James Morris <jmorris@redhat.com> _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
Reiner Sailer
2006-Sep-02 03:43 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
xense-devel-bounces@lists.xensource.com wrote on 09/01/2006 03:37:07 PM:> > > set_bit(_DOMF_privileged, &dom0->domain_flags); > > > /* post-create hooks sets security label */ > > > acm_post_domain0_create(dom0->domain_id); > > > + > > > + xsm_complete_init(dom0); > > > > Seems this should drop the acm hook here, no? > > > > We did not want the XSM patch to add XSM and remove ACM because we do > not believe that the community sees ACM and sHype as the distinct > entities that they really are. That''s why we have the patch that > removes the duplicated hooks and code and produces a module called ACM. > Hopefully in the future XSM will refer to the security framework and the > the STE/Chinese Wall functionality of ACM will be called the sHype > module. >XSM would effectively replace the small set of hooks that the sHype/ACM module introduced with a more generic mediation framework. sHype would use the XSM hook framework to control the same operations that it controls now. The way users interact with sHype(XSM) (tools, policies, labeling, ...) would not be affected by XSM. Instead of being both hooks and security module, sHype(XSM) would be a security module and XSM would offer the hooks. Ideally, XSM would be a standardized and generic Xen interface that offers the possibility for researchers to easily experiment with proprietary security modules. At the same time, it must have very low performance overhead and be effective to support enterprise security on highly utilized platforms. It is very good for starting the discussions that George and team succeeded to submit their code before the Xen Summit. Thank you! Regards Reiner _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
John McDermott (U.S. Navy Employee)
2006-Sep-05 16:25 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
Reiner Sailer wrote:> <snip> > XSM would effectively replace the small set of hooks that the > sHype/ACM module introduced with a more generic mediation framework. > sHype would use the XSM hook framework to control the same operations > that it controls now. The way users interact with sHype(XSM) (tools, > policies, labeling, ...) would not be affected by XSM. Instead of > being both hooks and security module, sHype(XSM) would be a security > module and XSM would offer the hooks. > > Ideally, XSM would be a standardized and generic Xen interface that > offers the possibility for researchers to easily experiment with > proprietary security modules. At the same time, it must have very low > performance overhead and be effective to support enterprise security > on highly utilized platforms. > > It is very good for starting the discussions that George and team > succeeded to submit their code before the Xen Summit. Thank you!The XSM concept looks good for prototyping and research but any security-related additions to Xen should be done in a way that does not increase the _minimum_ size of the code base. A small code base is essential for high assurance; having the flexibility of XSM is good but it should be possible to build a Xen with something smaller than XSM. If XSM or other security enhancements become too deeply associated with the core of Xen then we loose the chance to build high-assurance Xen-based products. This is really an issue about what kind of security the hypervisor should enforce and what should be enforced by trusted or untrusted (wrt the hypervisor) mechanisms outside the hypervisor. Sincerely, John -- J.P. McDermott building 12 Code 5542 mcdermott@itd.nrl.navy.mil Naval Research Laboratory voice: +1 202.404.8301 Washington, DC 20375, USA fax: +1 202.404.7942 _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
George S. Coker, II
2006-Sep-05 19:00 UTC
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
On Tue, 2006-09-05 at 12:25 -0400, John McDermott (U.S. Navy Employee) wrote:> The XSM concept looks good for prototyping and research but any > security-related additions to Xen should be done in a way that does not > increase the _minimum_ size of the code base. A small code base is > essential for high assurance; having the flexibility of XSM is good but > it should be possible to build a Xen with something smaller than XSM. If > XSM or other security enhancements become too deeply associated with the > core of Xen then we loose the chance to build high-assurance Xen-based > products. > > This is really an issue about what kind of security the hypervisor > should enforce and what should be enforced by trusted or untrusted (wrt > the hypervisor) mechanisms outside the hypervisor.I want to make a few points to clarify the value of XSM for Xen. I think the value goes well beyond prototyping and research. 1) XSM itself is small. Do not confuse XSM with XSM and any particular security module. XSM has actually made Xen smaller by encapsulating existing security code into a module that is not part of Xen. XSM without a module does not add security value to Xen. XSM can only provide security value in the presence of a security module. In fact, if you wish to have no security in Xen, XSM allows that too through the selection of the dummy module. 2) Any arguments about Xen''s size and assurance needs to include Xen with a security module and what the security module is doing for Xen. Discussion about particular security functionality can now be done in the context of a particular module not Xen. This adds value because we can now reason about what a particular security module is doing for Xen. 3) Analysis of Xen as a security kernel is only appropriate in the context of a particular security model. Whether that model is implemented in an XSM module or littered about Xen is immaterial. One might argue that XSM now creates a well defined internal security interface for Xen and makes it easier to reason about Xen as a security kernel. 4) Security in user-space needs a secure foundation. XSM allows that to be created on Xen with an appropriate choice of module. No one is arguing that all security should be implemented as an XSM module. XSM modules should only incorporate security functionality appropriate for the hypervisor; the remainder should be implemented in user-space. George> Sincerely, > > John >_______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel