[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.