On 09/28/2018 04:18 AM, Xin Li wrote:
Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy.

Signed-off-by: Xin Li <xin...@citrix.com>

This changes the default behavior of a hypervisor compiled with XSM+FLASK when
booted with no command line arguments from enabling FLASK to enabling the dummy
module.  I think the default value of the "xsm=" parameter should be settable
in Kconfig to allow existing systems to continue working after an upgrade.

If not, this new command line argument needs to be mentioned in more locations
in the documentation; at least docs/misc/xsm-flask "Setting up FLASK" will need
to mention it.  I think a mention in the release notes for the next version is
also a good idea (in addition to or as part of the note on the new SILO 
feature),
but that's not a part of the patch.

Untested Kconfig snippet:

choice
    prompt "Default XSM implementation"
    default XSM_FLASK_DEFAULT if XSM_FLASK
    default XSM_SILO_DEFAULT if XSM_SILO
    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
    config XSM_SILO_DEFAULT
        bool "SILO" if XSM_SILO
endchoice

The multiple "default" statements are intended to cause the default to be the
chosen enabled system, or dummy if there are no existing Kconfig settings.

I also think the question for XSM_FLASK should be removed from EXPERT now that
there is a reason to enable XSM without FLASK.

The name "default" might end up being misleading in this case; "none", "off",
or "dummy" might be better.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to