[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm
>>> On 29.09.18 at 11:22, <talons.lee@xxxxxxxxx> wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -899,6 +899,19 @@ hardware domain is architecture dependent. > Note that specifying zero as domU value means zero, while for dom0 it means > to use the default. > > +### xsm > +> `= dummy | flask` > + > +> Default: `dummy` > + > +Specify which XSM module should be enabled. This option is only available if > +the hypervisor was compiled with XSM support. > + > +* `dummy`: this is the default choice. Basic restriction for common > deployment > + (the dummy module) will be applied. it's also used when XSM is compiled > out. "It's" (upper case I). > +* `flask`: this is the policy based access control. To choose this, the > + separated option in kconfig must also be enabled. Perhaps better "separate" (but I'm not a native speaker)? > @@ -154,6 +154,17 @@ config XSM_FLASK_POLICY > > If unsure, say Y. > > +choice > + prompt "Default XSM implementation" > + depends on XSM > + default XSM_FLASK_DEFAULT if XSM_FLASK > + default XSM_DUMMY_DEFAULT > + config XSM_DUMMY_DEFAULT > + bool "Match non-XSM behavior" > + config XSM_FLASK_DEFAULT > + bool "FLux Advanced Security Kernel" if XSM_FLASK > +endchoice Personally I'd prefer XSM_DEFAULT_*; not sure what others think. > --- a/xen/xsm/xsm_core.c > +++ b/xen/xsm/xsm_core.c > @@ -31,6 +31,37 @@ > > struct xsm_operations *xsm_ops; > > +enum xsm_bootparam { > + XSM_BOOTPARAM_DUMMY, > + XSM_BOOTPARAM_FLASK, Considering the #ifdef-s further down, should this perhaps also be put in "#ifdef CONFIG_XSM_FLASK", to avoid it mistakenly getting used when the code was compiled out? > +}; > + > +static enum xsm_bootparam __initdata xsm_bootparam = > +#ifdef CONFIG_XSM_FLASK_DEFAULT > + XSM_BOOTPARAM_FLASK; > +#else > + XSM_BOOTPARAM_DUMMY; > +#endif > + > +static int __init parse_xsm_param(const char *s) > +{ > + int rc = 0; > + > + if ( !strcmp(s, "dummy") ) > + xsm_bootparam = XSM_BOOTPARAM_DUMMY; > +#ifdef CONFIG_XSM_FLASK > + else if ( !strcmp(s, "flask") ) > + xsm_bootparam = XSM_BOOTPARAM_FLASK; > +#endif > + else { Style (brace goes on its own line). > + printk("XSM: can't parse boot parameter xsm=%s\n", s); Again, not being a native speaker, "can't parse" sounds odd. Why not just "unknown" or "unknown or unsupported"? > @@ -57,7 +88,20 @@ static int __init xsm_core_init(const void *policy_buffer, > size_t policy_size) > } > > xsm_ops = &dummy_xsm_ops; > - flask_init(policy_buffer, policy_size); > + > + switch ( xsm_bootparam ) > + { > + case XSM_BOOTPARAM_DUMMY: > + break; > + > + case XSM_BOOTPARAM_FLASK: > + flask_init(policy_buffer, policy_size); > + break; > + > + default: > + printk("XSM: Invalid value for xsm= boot parameter\n"); > + break; What situation is this covering, when all enumerators already have their case label? Simply ASSERT_UNREACHABLE()? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |