[PATCH] tools: make flask utils build unconditional

[PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

The flask utilities only have dependencies on libxc so there's no
downside to always building it. Distros and projects based on Xen can
put these utilities into a different package and not install them for
everyone. Prior to this change FLASK_ENABLE needs to be a top level
variable however after this change FLASK_ENABLE only affects xen/.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 820ca40..2f773fd 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 SUBDIRS-y :=
 SUBDIRS-y += include
 SUBDIRS-y += libxc
-SUBDIRS-$(FLASK_ENABLE) += flask
+SUBDIRS-y += flask
 SUBDIRS-y += xenstore
 SUBDIRS-y += misc
 SUBDIRS-y += examples
-- 
2.4.10

Re: [PATCH] tools: make flask utils build unconditional

[Andrew Cooper]

On 22/12/15 04:46, Doug Goldstein wrote:
> The flask utilities only have dependencies on libxc so there's no
> downside to always building it. Distros and projects based on Xen can
> put these utilities into a different package and not install them for
> everyone. Prior to this change FLASK_ENABLE needs to be a top level
> variable however after this change FLASK_ENABLE only affects xen/.
>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

CC'ing Daniel as this is a flask related change.

FWIW, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  tools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 820ca40..2f773fd 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  SUBDIRS-y :=
>  SUBDIRS-y += include
>  SUBDIRS-y += libxc
> -SUBDIRS-$(FLASK_ENABLE) += flask
> +SUBDIRS-y += flask
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples

[PATCH 1/2] xen: convert FLASK_ENABLE to Kconfig

[Doug Goldstein]

Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.

CC: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
 Config.mk                |  1 -
 INSTALL                  |  6 +++++-
 docs/misc/xsm-flask.txt  |  5 +++--
 xen/Rules.mk             |  1 -
 xen/common/Kconfig       | 11 +++++++++++
 xen/include/Makefile     |  2 +-
 xen/include/xen/config.h |  2 +-
 xen/include/xen/sched.h  |  2 +-
 xen/xsm/Makefile         |  2 +-
 9 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7b2aa07..7e56b48 100644
--- a/Config.mk
+++ b/Config.mk
@@ -214,7 +214,6 @@ EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
-FLASK_ENABLE ?= $(XSM_ENABLE)
 
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
diff --git a/INSTALL b/INSTALL
index b7e426c..c51447b 100644
--- a/INSTALL
+++ b/INSTALL
@@ -278,7 +278,11 @@ PYTHON_PREFIX_ARG=
 The hypervisor may be build with XSM support, which can be changed with
 the following variables.
 XSM_ENABLE=y
-FLASK_ENABLE=y
+
+The hypervisor may be build with Flask support, which can be changed
+by running:
+make -C xen menuconfig
+and enabling Flask in the 'Common Features' menu.
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 7249f40..f2f0fd4 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -172,8 +172,9 @@ Setting up FLASK
 ----------------
 
 Xen must be compiled with XSM and FLASK enabled; by default, the security
-framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE and
-FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
+framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE to
+"y" and running 'make -C xen menuconfig' and enabling FLASK inside 'Common
+Features'; this change requires a make clean and rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8839dca..489cfd1 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -53,7 +53,6 @@ CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
-CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE
 CFLAGS-$(verbose)       += -DVERBOSE
 CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 046e257..3419816 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -8,6 +8,17 @@ config COMPAT
 	  HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
 	  of the destination runmode of the guest.
 
+config FLASK
+	bool "FLux Advanced Security Kernel support"
+	default n
+	---help---
+	  Enables the FLASK (FLux Advanced Security Kernel) support which
+	  provides a mandatory access control framework by which security
+	  enforcement, isolation, and auditing can be achieved with fine
+	  granular control via a security policy.
+
+	  If unsure, say N.
+
 # Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
 	bool
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94ba3d8..9c8188b 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -28,7 +28,7 @@ headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-$(compat-arch-y).h
 headers-$(CONFIG_X86)     += compat/hvm/hvm_vcpu.h
 headers-y                 += compat/arch-$(compat-arch-y).h compat/pmu.h compat/xlat.h
-headers-$(FLASK_ENABLE)   += compat/xsm/flask_op.h
+headers-$(CONFIG_FLASK)   += compat/xsm/flask_op.h
 
 cppflags-y                := -include public/xen-compat.h
 cppflags-$(CONFIG_X86)    += -m32
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 7595599..bba015a 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -86,7 +86,7 @@
 #define mk_unsigned_long(x) x
 #endif /* !__ASSEMBLY__ */
 
-#ifdef FLASK_ENABLE
+#ifdef CONFIG_FLASK
 #define XSM_MAGIC 0xf97cff8c
 /* Maintain statistics on the access vector cache */
 #define FLASK_AVC_STATS 1
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fc61fc3..6ea3cc7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -119,7 +119,7 @@ struct evtchn
          */
         void *generic;
 #endif
-#ifdef FLASK_ENABLE
+#ifdef CONFIG_FLASK
         /*
          * Inlining the contents of the structure for FLASK avoids unneeded
          * allocations, and on 64-bit platforms with only FLASK enabled,
diff --git a/xen/xsm/Makefile b/xen/xsm/Makefile
index 16c13b5..d29e71c 100644
--- a/xen/xsm/Makefile
+++ b/xen/xsm/Makefile
@@ -4,4 +4,4 @@ obj-y += xsm_policy.o
 obj-y += dummy.o
 endif
 
-subdir-$(FLASK_ENABLE) += flask
+subdir-$(CONFIG_FLASK) += flask
-- 
2.4.10

[PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Doug Goldstein]

Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
CONFIG_XSM.

CC: Daniel De Graaf <dgdegra@tycho.nsa.gov>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
 Config.mk                    |  3 ---
 INSTALL                      |  8 ++------
 docs/misc/xsm-flask.txt      |  6 +++---
 xen/Rules.mk                 |  1 -
 xen/common/Kconfig           | 23 ++++++++++++++++++++++-
 xen/include/asm-x86/config.h |  4 ----
 xen/include/xen/sched.h      |  2 +-
 xen/include/xsm/dummy.h      | 10 +++++-----
 xen/include/xsm/xsm.h        |  6 +++---
 xen/xsm/Makefile             |  6 ++----
 10 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7e56b48..8e58c36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -212,9 +212,6 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE ?= n
-
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/INSTALL b/INSTALL
index c51447b..3d2e86a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -275,14 +275,10 @@ Building the python tools may fail unless certain options are passed to
 setup.py. Config.mk contains additional info how to use this variable.
 PYTHON_PREFIX_ARG=
 
-The hypervisor may be build with XSM support, which can be changed with
-the following variables.
-XSM_ENABLE=y
-
-The hypervisor may be build with Flask support, which can be changed
+he hypervisor may be build with XSM/Flask support, which can be changed
 by running:
 make -C xen menuconfig
-and enabling Flask in the 'Common Features' menu.
+and enabling XSM/Flask in the 'Common Features' menu.
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index f2f0fd4..fb2fe9f 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -172,9 +172,9 @@ Setting up FLASK
 ----------------
 
 Xen must be compiled with XSM and FLASK enabled; by default, the security
-framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE to
-"y" and running 'make -C xen menuconfig' and enabling FLASK inside 'Common
-Features'; this change requires a make clean and rebuild.
+framework is disabled. Running 'make -C xen menuconfig' and enabling XSM
+and FLASK inside 'Common Features'; this change requires a make clean and
+rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 489cfd1..bdd8ccf 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,7 +52,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
-CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
 CFLAGS-$(verbose)       += -DVERBOSE
 CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3419816..dea01eb 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -10,7 +10,8 @@ config COMPAT
 
 config FLASK
 	bool "FLux Advanced Security Kernel support"
-	default n
+	default y
+	depends on XSM
 	---help---
 	  Enables the FLASK (FLux Advanced Security Kernel) support which
 	  provides a mandatory access control framework by which security
@@ -62,4 +63,24 @@ config KEXEC
 
 	  If unsure, say Y.
 
+# Allows "late" initialization of the hardware domain
+config LATE_HWDOM
+	bool
+	---help---
+	  Late hardware domain initialization
+
+# Enable/Disable XSM support
+config XSM
+	bool "Xen Security Modules support"
+	default n
+	select LATE_HWDOM if X86
+	---help---
+	  Enables the security framework known as Xen Security Modules which
+	  allows administrators fine-grained control over a Xen domain and
+	  its capabilities by defining permissible interactions between domains,
+	  the hypervisor itself, and related resources such as memory and
+	  devices.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index f25d92e..3305a75 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -52,10 +52,6 @@
 
 #define CONFIG_MULTIBOOT 1
 
-#ifdef XSM_ENABLE
-#define CONFIG_LATE_HWDOM 1
-#endif
-
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6ea3cc7..e1428f7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -110,7 +110,7 @@ struct evtchn
     u8 priority;
     u8 last_priority;
     u16 last_vcpu_id;
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
     union {
 #ifdef XSM_NEED_GENERIC_EVTCHN_SSID
         /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 81fba40..55b84f0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -27,9 +27,9 @@
 /* DO NOT implement this function; it is supposed to trigger link errors */
 void __xsm_action_mismatch_detected(void);
 
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
 
-/* In XSM_ENABLE builds, this header file is included from xsm/dummy.c, and
+/* In CONFIG_XSM builds, this header file is included from xsm/dummy.c, and
  * contains static (not inline) functions compiled to the dummy XSM module.
  * There is no xsm_default_t argument available, so the value from the assertion
  * is used to initialize the variable.
@@ -39,9 +39,9 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_DEFAULT_VOID void
 #define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
 
-#else /* XSM_ENABLE */
+#else /* CONFIG_XSM */
 
-/* In !XSM_ENABLE builds, this header file is included from xsm/xsm.h, and
+/* In !CONFIG_XSM builds, this header file is included from xsm/xsm.h, and
  * contains inline functions for each XSM hook. These functions also perform
  * compile-time checks on the xsm_default_t argument to ensure that the behavior
  * of the dummy XSM module is the same as the behavior with XSM disabled.
@@ -51,7 +51,7 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_DEFAULT_VOID xsm_default_t action
 #define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
 
-#endif /* XSM_ENABLE */
+#endif /* CONFIG_XSM */
 
 static always_inline int xsm_default_action(
     xsm_default_t action, struct domain *src, struct domain *target)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3fc3824..2c365cd 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -194,7 +194,7 @@ struct xsm_operations {
 #endif
 };
 
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
 
 extern struct xsm_operations *xsm_ops;
 
@@ -752,7 +752,7 @@ extern int unregister_xsm(struct xsm_operations *ops);
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
-#else /* XSM_ENABLE */
+#else /* CONFIG_XSM */
 
 #include <xsm/dummy.h>
 
@@ -772,6 +772,6 @@ static inline int xsm_dt_init(void)
 }
 #endif
 
-#endif /* XSM_ENABLE */
+#endif /* CONFIG_XSM */
 
 #endif /* __XSM_H */
diff --git a/xen/xsm/Makefile b/xen/xsm/Makefile
index d29e71c..3252c46 100644
--- a/xen/xsm/Makefile
+++ b/xen/xsm/Makefile
@@ -1,7 +1,5 @@
 obj-y += xsm_core.o
-ifeq ($(XSM_ENABLE),y)
-obj-y += xsm_policy.o
-obj-y += dummy.o
-endif
+obj-$(CONFIG_XSM) += xsm_policy.o
+obj-$(CONFIG_XSM) += dummy.o
 
 subdir-$(CONFIG_FLASK) += flask
-- 
2.4.10

Re: [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Andrew Cooper]

On 22/12/2015 21:26, Doug Goldstein wrote:
> diff --git a/INSTALL b/INSTALL
> index c51447b..3d2e86a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -275,14 +275,10 @@ Building the python tools may fail unless certain options are passed to
>  setup.py. Config.mk contains additional info how to use this variable.
>  PYTHON_PREFIX_ARG=
>  
> -The hypervisor may be build with XSM support, which can be changed with
> -the following variables.
> -XSM_ENABLE=y
> -
> -The hypervisor may be build with Flask support, which can be changed
> +he hypervisor may be build with XSM/Flask support, which can be changed

Missing a T.

The x86 bits appear to be entirely mechanical, so Acked-by: Andrew
Cooper <andrew.cooper3@citrix.com>

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote:
> The flask utilities only have dependencies on libxc so there's no
> downside to always building it. Distros and projects based on Xen can
> put these utilities into a different package and not install them for
> everyone. Prior to this change FLASK_ENABLE needs to be a top level
> variable however after this change FLASK_ENABLE only affects xen/.
> 
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

While it is true about the dependency, enabling flask build
unconditionally in toolstack will leave a xenpolicy-$VERSION installed
in /boot. Not sure how that will be useful to Xen without flask support.

It is true that packager can pick that into separate package, but for
people installing from source, this might be a bit confusing.

Wei.

> ---
>  tools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 820ca40..2f773fd 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  SUBDIRS-y :=
>  SUBDIRS-y += include
>  SUBDIRS-y += libxc
> -SUBDIRS-$(FLASK_ENABLE) += flask
> +SUBDIRS-y += flask
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples
> -- 
> 2.4.10
> 

Re: [PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

On 1/4/16 6:28 AM, Wei Liu wrote:
> On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote:
>> The flask utilities only have dependencies on libxc so there's no
>> downside to always building it. Distros and projects based on Xen can
>> put these utilities into a different package and not install them for
>> everyone. Prior to this change FLASK_ENABLE needs to be a top level
>> variable however after this change FLASK_ENABLE only affects xen/.
>>
>> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> 
> While it is true about the dependency, enabling flask build
> unconditionally in toolstack will leave a xenpolicy-$VERSION installed
> in /boot. Not sure how that will be useful to Xen without flask support.
> 
> It is true that packager can pick that into separate package, but for
> people installing from source, this might be a bit confusing.
> 
> Wei.

Wei,

This is actually not correct. The installation of that file is
controlled by the ./configure script with --enable-xsmpolicy and
--disable-xsmpolicy.

This patch just makes the utilities be unconditionally built.

--
Doug


> 
>> ---
>>  tools/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/Makefile b/tools/Makefile
>> index 820ca40..2f773fd 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>>  SUBDIRS-y :=
>>  SUBDIRS-y += include
>>  SUBDIRS-y += libxc
>> -SUBDIRS-$(FLASK_ENABLE) += flask
>> +SUBDIRS-y += flask
>>  SUBDIRS-y += xenstore
>>  SUBDIRS-y += misc
>>  SUBDIRS-y += examples
>> -- 
>> 2.4.10
>>


-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Mon, Jan 04, 2016 at 08:14:23AM -0600, Doug Goldstein wrote:
> On 1/4/16 6:28 AM, Wei Liu wrote:
> > On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote:
> >> The flask utilities only have dependencies on libxc so there's no
> >> downside to always building it. Distros and projects based on Xen can
> >> put these utilities into a different package and not install them for
> >> everyone. Prior to this change FLASK_ENABLE needs to be a top level
> >> variable however after this change FLASK_ENABLE only affects xen/.
> >>
> >> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> > 
> > While it is true about the dependency, enabling flask build
> > unconditionally in toolstack will leave a xenpolicy-$VERSION installed
> > in /boot. Not sure how that will be useful to Xen without flask support.
> > 
> > It is true that packager can pick that into separate package, but for
> > people installing from source, this might be a bit confusing.
> > 
> > Wei.
> 
> Wei,
> 
> This is actually not correct. The installation of that file is
> controlled by the ./configure script with --enable-xsmpolicy and
> --disable-xsmpolicy.
> 
> This patch just makes the utilities be unconditionally built.
> 

You're right. I misread. Sorry for the noise.

Acked-by: Wei Liu <wei.liu2@citrix.com>

Wei.

Re: [PATCH 1/2] xen: convert FLASK_ENABLE to Kconfig

[Daniel De Graaf]

On 22/12/15 16:26, Doug Goldstein wrote:
> Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
> the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
> dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
> is converted to Kconfig.
>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Assuming that both patches in this series are applied together,
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Re: [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Daniel De Graaf]

On 22/12/15 16:26, Doug Goldstein wrote:
> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
> CONFIG_XSM.
>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

The dependencies for LATE_HWDOM are backwards: it is an optional X86-only
feature (which probably should be off by default) that depends on XSM to
work properly.

How about this for the help text:

Allows the creation of a dedicated hardware domain distinct from
domain 0 that manages devices without needing access to other
privileged functionality such as the ability to manage domains.
This requires that the actual domain 0 be a stub domain that
constructs the actual hardware domain instead of initializing the
hardware itself.  Because the hardware domain needs access to
hypercalls not available to unprivileged guests, an XSM policy
is required to properly define the privilege of these domains.

This feature does nothing if the "hardware_dom" boot parameter is
not present.  If this feature is being used for security, it should
be combined with an IOMMU in strict mode.

If unsure, say N.

Re: [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --]

On 1/4/16 2:01 PM, Daniel De Graaf wrote:
> On 22/12/15 16:26, Doug Goldstein wrote:
>> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
>> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
>> CONFIG_XSM.
>>
>> CC: Keir Fraser <keir@xen.org>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> 
> The dependencies for LATE_HWDOM are backwards: it is an optional X86-only
> feature (which probably should be off by default) that depends on XSM to
> work properly.

Currently its always enabled if XSM_ENABLE is set. But if you are
comfortable I'll tweak the patch to make this adjustable. Are you ok
keeping your Ack-by as well?

> 
> How about this for the help text:
> 
> Allows the creation of a dedicated hardware domain distinct from
> domain 0 that manages devices without needing access to other
> privileged functionality such as the ability to manage domains.
> This requires that the actual domain 0 be a stub domain that
> constructs the actual hardware domain instead of initializing the
> hardware itself.  Because the hardware domain needs access to
> hypercalls not available to unprivileged guests, an XSM policy
> is required to properly define the privilege of these domains.
> 
> This feature does nothing if the "hardware_dom" boot parameter is
> not present.  If this feature is being used for security, it should
> be combined with an IOMMU in strict mode.
> 
> If unsure, say N.

Perfect! This is what I'm looking for from the various maintainers to
help improve the documentation of different flags.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Daniel De Graaf]

On 04/01/16 15:33, Doug Goldstein wrote:
> On 1/4/16 2:01 PM, Daniel De Graaf wrote:
>> On 22/12/15 16:26, Doug Goldstein wrote:
>>> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
>>> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
>>> CONFIG_XSM.
>>>
>>> CC: Keir Fraser <keir@xen.org>
>>> CC: Jan Beulich <jbeulich@suse.com>
>>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
>>
>> The dependencies for LATE_HWDOM are backwards: it is an optional X86-only
>> feature (which probably should be off by default) that depends on XSM to
>> work properly.
>
> Currently its always enabled if XSM_ENABLE is set. But if you are
> comfortable I'll tweak the patch to make this adjustable. Are you ok
> keeping your Ack-by as well?

Yes; Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

[PATCH v2 2/2] xen: convert XSM_ENABLE to Kconfig

[Doug Goldstein]

Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
CONFIG_XSM.

CC: Daniel De Graaf <dgdegra@tycho.nsa.gov>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
Change from v2:
- adopt wording from Daniel De Graaf about the dedicated hardware domain
- make the dedicated hardware domain feature optional
---
 Config.mk                    |  3 ---
 INSTALL                      |  8 ++------
 docs/misc/xsm-flask.txt      |  6 +++---
 xen/Rules.mk                 |  1 -
 xen/common/Kconfig           | 37 ++++++++++++++++++++++++++++++++++++-
 xen/include/asm-x86/config.h |  4 ----
 xen/include/xen/sched.h      |  2 +-
 xen/include/xsm/dummy.h      | 10 +++++-----
 xen/include/xsm/xsm.h        |  6 +++---
 xen/xsm/Makefile             |  6 ++----
 10 files changed, 52 insertions(+), 31 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7e56b48..8e58c36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -212,9 +212,6 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE ?= n
-
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/INSTALL b/INSTALL
index c51447b..3d2e86a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -275,14 +275,10 @@ Building the python tools may fail unless certain options are passed to
 setup.py. Config.mk contains additional info how to use this variable.
 PYTHON_PREFIX_ARG=
 
-The hypervisor may be build with XSM support, which can be changed with
-the following variables.
-XSM_ENABLE=y
-
-The hypervisor may be build with Flask support, which can be changed
+he hypervisor may be build with XSM/Flask support, which can be changed
 by running:
 make -C xen menuconfig
-and enabling Flask in the 'Common Features' menu.
+and enabling XSM/Flask in the 'Common Features' menu.
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index f2f0fd4..fb2fe9f 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -172,9 +172,9 @@ Setting up FLASK
 ----------------
 
 Xen must be compiled with XSM and FLASK enabled; by default, the security
-framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE to
-"y" and running 'make -C xen menuconfig' and enabling FLASK inside 'Common
-Features'; this change requires a make clean and rebuild.
+framework is disabled. Running 'make -C xen menuconfig' and enabling XSM
+and FLASK inside 'Common Features'; this change requires a make clean and
+rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 489cfd1..bdd8ccf 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,7 +52,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
-CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
 CFLAGS-$(verbose)       += -DVERBOSE
 CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3419816..eadfc3b 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -10,7 +10,8 @@ config COMPAT
 
 config FLASK
 	bool "FLux Advanced Security Kernel support"
-	default n
+	default y
+	depends on XSM
 	---help---
 	  Enables the FLASK (FLux Advanced Security Kernel) support which
 	  provides a mandatory access control framework by which security
@@ -62,4 +63,38 @@ config KEXEC
 
 	  If unsure, say Y.
 
+# Allows "late" initialization of the hardware domain
+config LATE_HWDOM
+	bool "dedicated hardware domain"
+	default n
+	depends on XSM && X86
+	---help---
+	  Allows the creation of a dedicated hardware domain distinct from
+	  domain 0 that manages devices without needing access to other
+	  privileged functionality such as the ability to manage domains.
+	  This requires that the actual domain 0 be a stub domain that
+	  constructs the actual hardware domain instead of initializing the
+	  hardware itself.  Because the hardware domain needs access to
+	  hypercalls not available to unprivileged guests, an XSM policy
+	  is required to properly define the privilege of these domains.
+
+	  This feature does nothing if the "hardware_dom" boot parameter is
+	  not present.  If this feature is being used for security, it should
+	  be combined with an IOMMU in strict mode.
+
+	  If unsure, say N.
+
+# Enable/Disable XSM support
+config XSM
+	bool "Xen Security Modules support"
+	default n
+	---help---
+	  Enables the security framework known as Xen Security Modules which
+	  allows administrators fine-grained control over a Xen domain and
+	  its capabilities by defining permissible interactions between domains,
+	  the hypervisor itself, and related resources such as memory and
+	  devices.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index f25d92e..3305a75 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -52,10 +52,6 @@
 
 #define CONFIG_MULTIBOOT 1
 
-#ifdef XSM_ENABLE
-#define CONFIG_LATE_HWDOM 1
-#endif
-
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6ea3cc7..e1428f7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -110,7 +110,7 @@ struct evtchn
     u8 priority;
     u8 last_priority;
     u16 last_vcpu_id;
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
     union {
 #ifdef XSM_NEED_GENERIC_EVTCHN_SSID
         /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 81fba40..55b84f0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -27,9 +27,9 @@
 /* DO NOT implement this function; it is supposed to trigger link errors */
 void __xsm_action_mismatch_detected(void);
 
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
 
-/* In XSM_ENABLE builds, this header file is included from xsm/dummy.c, and
+/* In CONFIG_XSM builds, this header file is included from xsm/dummy.c, and
  * contains static (not inline) functions compiled to the dummy XSM module.
  * There is no xsm_default_t argument available, so the value from the assertion
  * is used to initialize the variable.
@@ -39,9 +39,9 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_DEFAULT_VOID void
 #define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
 
-#else /* XSM_ENABLE */
+#else /* CONFIG_XSM */
 
-/* In !XSM_ENABLE builds, this header file is included from xsm/xsm.h, and
+/* In !CONFIG_XSM builds, this header file is included from xsm/xsm.h, and
  * contains inline functions for each XSM hook. These functions also perform
  * compile-time checks on the xsm_default_t argument to ensure that the behavior
  * of the dummy XSM module is the same as the behavior with XSM disabled.
@@ -51,7 +51,7 @@ void __xsm_action_mismatch_detected(void);
 #define XSM_DEFAULT_VOID xsm_default_t action
 #define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
 
-#endif /* XSM_ENABLE */
+#endif /* CONFIG_XSM */
 
 static always_inline int xsm_default_action(
     xsm_default_t action, struct domain *src, struct domain *target)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3fc3824..2c365cd 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -194,7 +194,7 @@ struct xsm_operations {
 #endif
 };
 
-#ifdef XSM_ENABLE
+#ifdef CONFIG_XSM
 
 extern struct xsm_operations *xsm_ops;
 
@@ -752,7 +752,7 @@ extern int unregister_xsm(struct xsm_operations *ops);
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
-#else /* XSM_ENABLE */
+#else /* CONFIG_XSM */
 
 #include <xsm/dummy.h>
 
@@ -772,6 +772,6 @@ static inline int xsm_dt_init(void)
 }
 #endif
 
-#endif /* XSM_ENABLE */
+#endif /* CONFIG_XSM */
 
 #endif /* __XSM_H */
diff --git a/xen/xsm/Makefile b/xen/xsm/Makefile
index d29e71c..3252c46 100644
--- a/xen/xsm/Makefile
+++ b/xen/xsm/Makefile
@@ -1,7 +1,5 @@
 obj-y += xsm_core.o
-ifeq ($(XSM_ENABLE),y)
-obj-y += xsm_policy.o
-obj-y += dummy.o
-endif
+obj-$(CONFIG_XSM) += xsm_policy.o
+obj-$(CONFIG_XSM) += dummy.o
 
 subdir-$(CONFIG_FLASK) += flask
-- 
2.4.10

Re: [PATCH] tools: make flask utils build unconditional

[Ian Campbell]

On Mon, 2016-01-04 at 14:26 +0000, Wei Liu wrote:
> On Mon, Jan 04, 2016 at 08:14:23AM -0600, Doug Goldstein wrote:
> > On 1/4/16 6:28 AM, Wei Liu wrote:
> > > On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote:
> > > > The flask utilities only have dependencies on libxc so there's no
> > > > downside to always building it. Distros and projects based on Xen
> > > > can
> > > > put these utilities into a different package and not install them
> > > > for
> > > > everyone. Prior to this change FLASK_ENABLE needs to be a top level
> > > > variable however after this change FLASK_ENABLE only affects xen/.
> > > > 
> > > > Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> > > 
> > > While it is true about the dependency, enabling flask build
> > > unconditionally in toolstack will leave a xenpolicy-$VERSION
> > > installed
> > > in /boot. Not sure how that will be useful to Xen without flask
> > > support.
> > > 
> > > It is true that packager can pick that into separate package, but for
> > > people installing from source, this might be a bit confusing.
> > > 
> > > Wei.
> > 
> > Wei,
> > 
> > This is actually not correct. The installation of that file is
> > controlled by the ./configure script with --enable-xsmpolicy and
> > --disable-xsmpolicy.
> > 
> > This patch just makes the utilities be unconditionally built.
> > 
> 
> You're right. I misread. Sorry for the noise.
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>

I went to apply this but I seem to now have an extra policy file installed
after my test build:
--- ../FILE_LIST.BASE.staging.x86_64    2015-12-16 09:45:00.000000000 +0000
+++ ../FILE_LIST.staging.x86_64 2016-01-05 14:27:58.000000000 +0000
@@ -6,6 +6,7 @@
 dist/install/boot/xen-4.7-unstable.gz
 dist/install/boot/xen-4.gz
 dist/install/boot/xen.gz
+dist/install/boot/xenpolicy-4.7-unstable
 dist/install/etc
 dist/install/etc/bash_completion.d
 dist/install/etc/bash_completion.d/xl.sh

which on the basis of this discussion I wasn't expecting. I didn't see this
new file on i686 or ARM*.

My baseline is from the last time I committed, which would be last year, so
maybe something other than my current batch of patches has caused this.

I'm going to drop this one for now and (hopefully) get the rest of the
batch squared away. Afterwards I'll take another look (with a new baseline
filelist), but if someone can explain it in the meantime that would be
super.

My pre-commit script doesn't mention xsm at all, i.e. nothing passed to
./configure nor written to .config or xen/.config.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Ian Campbell]

On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
> 
> which on the basis of this discussion I wasn't expecting. I didn't see this
> new file on i686 or ARM*.
> 
> My baseline is from the last time I committed, which would be last year, so
> maybe something other than my current batch of patches has caused this.
> 
> I'm going to drop this one for now and (hopefully) get the rest of the
> batch squared away. Afterwards I'll take another look (with a new baseline
> filelist), but if someone can explain it in the meantime that would be
> super.

So with a fresh basline I still see:

--- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000 +0000
+++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
@@ -6,6 +6,7 @@
 dist/install/boot/xen-4.7-unstable.gz
 dist/install/boot/xen-4.gz
 dist/install/boot/xen.gz
+dist/install/boot/xenpolicy-4.7-unstable
 dist/install/etc
 dist/install/etc/bash_completion.d
 dist/install/etc/bash_completion.d/xl.sh
@@ -386,6 +387,12 @@
 dist/install/usr/local/lib/xen/libexec
 dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
 dist/install/usr/local/sbin
+dist/install/usr/local/sbin/flask-get-bool
+dist/install/usr/local/sbin/flask-getenforce
+dist/install/usr/local/sbin/flask-label-pci
+dist/install/usr/local/sbin/flask-loadpolicy
+dist/install/usr/local/sbin/flask-set-bool
+dist/install/usr/local/sbin/flask-setenforce
 dist/install/usr/local/sbin/gdbsx
 dist/install/usr/local/sbin/gtracestat
 dist/install/usr/local/sbin/gtraceview
*** FILES DIFFER ***

On i686 and ARM* I only see the (expected) second hunk.

I think the i686 case is explainable by the lack of a hypervisor build
there, but I'm unsure why ARM* and x86_64 should differ in this regard.

config/Tools.mk is y only on x86_64, not on the others, which obviously
explains things, but the question is why only on x86_64 (I presume this has
always been the case and it was previously masked, but I've not checked).

Ah, OK, I misread

AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])

as being default disable, actually the default is "enabled iff checkpolicy
is installed" and it happens to be that it is only installed in my x86_64
build env.

So, in the end I think Wei was correct and this change will now, in some
circumstances, end up installing a /boot/xenpolicy-*.

So the question is do we mind that?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
> On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
> > 
> > which on the basis of this discussion I wasn't expecting. I didn't see this
> > new file on i686 or ARM*.
> > 
> > My baseline is from the last time I committed, which would be last year, so
> > maybe something other than my current batch of patches has caused this.
> > 
> > I'm going to drop this one for now and (hopefully) get the rest of the
> > batch squared away. Afterwards I'll take another look (with a new baseline
> > filelist), but if someone can explain it in the meantime that would be
> > super.
> 
> So with a fresh basline I still see:
> 
> --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000 +0000
> +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
> @@ -6,6 +6,7 @@
>  dist/install/boot/xen-4.7-unstable.gz
>  dist/install/boot/xen-4.gz
>  dist/install/boot/xen.gz
> +dist/install/boot/xenpolicy-4.7-unstable
>  dist/install/etc
>  dist/install/etc/bash_completion.d
>  dist/install/etc/bash_completion.d/xl.sh
> @@ -386,6 +387,12 @@
>  dist/install/usr/local/lib/xen/libexec
>  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
>  dist/install/usr/local/sbin
> +dist/install/usr/local/sbin/flask-get-bool
> +dist/install/usr/local/sbin/flask-getenforce
> +dist/install/usr/local/sbin/flask-label-pci
> +dist/install/usr/local/sbin/flask-loadpolicy
> +dist/install/usr/local/sbin/flask-set-bool
> +dist/install/usr/local/sbin/flask-setenforce
>  dist/install/usr/local/sbin/gdbsx
>  dist/install/usr/local/sbin/gtracestat
>  dist/install/usr/local/sbin/gtraceview
> *** FILES DIFFER ***
> 
> On i686 and ARM* I only see the (expected) second hunk.
> 
> I think the i686 case is explainable by the lack of a hypervisor build
> there, but I'm unsure why ARM* and x86_64 should differ in this regard.
> 
> config/Tools.mk is y only on x86_64, not on the others, which obviously
> explains things, but the question is why only on x86_64 (I presume this has
> always been the case and it was previously masked, but I've not checked).
> 
> Ah, OK, I misread
> 
> AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
> 
> as being default disable, actually the default is "enabled iff checkpolicy
> is installed" and it happens to be that it is only installed in my x86_64
> build env.
> 
> So, in the end I think Wei was correct and this change will now, in some
> circumstances, end up installing a /boot/xenpolicy-*.
> 

I don't think it is related to this patch. I see an xenpoilcy file
without this patch applied. As you said it only depends on availability
of checkpolicy (part of generic SELinux utils, not the ones we build).

That said, let me try to answer the following question.

> So the question is do we mind that?
> 

We might or might not. See below.

I once submitted a patch to grub that look into /boot and generate XSM
entries if there is policy file. The patch is not yet merged though.

Since there is no way at the moment to tell if xen.gz has flask enabled,
my not yet upstreamed patch only matches the version number of xen.gz and
xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
make grub generate an XSM entry nonetheless, which makes no sense.

Of course all the above is based on the theory that my grub patch is
going to be upstreamed.

Things have changed since I first submitted that patch. Doug's Kconfig
work is good. With .config installed in suitable location we can make
grub grep for flask information in config, hence avoiding generating
wrong entries.  I think this is better solution as we don't need to use
version number to match xen.gz and xenpolicy. If we go down this route
we don't mind having random xenpolicy lying around in /boot.

We just need to reach an agreement on how to proceed. I would vote for
the second solution.

Wei.


> Ian.

Re: [PATCH] tools: make flask utils build unconditional

[Ian Campbell]

On Tue, 2016-01-05 at 16:13 +0000, Wei Liu wrote:
> On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
> > On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
> > > 
> > > which on the basis of this discussion I wasn't expecting. I didn't
> > > see this
> > > new file on i686 or ARM*.
> > > 
> > > My baseline is from the last time I committed, which would be last
> > > year, so
> > > maybe something other than my current batch of patches has caused
> > > this.
> > > 
> > > I'm going to drop this one for now and (hopefully) get the rest of
> > > the
> > > batch squared away. Afterwards I'll take another look (with a new
> > > baseline
> > > filelist), but if someone can explain it in the meantime that would
> > > be
> > > super.
> > 
> > So with a fresh basline I still see:
> > 
> > --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000
> > +0000
> > +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
> > @@ -6,6 +6,7 @@
> >  dist/install/boot/xen-4.7-unstable.gz
> >  dist/install/boot/xen-4.gz
> >  dist/install/boot/xen.gz
> > +dist/install/boot/xenpolicy-4.7-unstable
> >  dist/install/etc
> >  dist/install/etc/bash_completion.d
> >  dist/install/etc/bash_completion.d/xl.sh
> > @@ -386,6 +387,12 @@
> >  dist/install/usr/local/lib/xen/libexec
> >  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
> >  dist/install/usr/local/sbin
> > +dist/install/usr/local/sbin/flask-get-bool
> > +dist/install/usr/local/sbin/flask-getenforce
> > +dist/install/usr/local/sbin/flask-label-pci
> > +dist/install/usr/local/sbin/flask-loadpolicy
> > +dist/install/usr/local/sbin/flask-set-bool
> > +dist/install/usr/local/sbin/flask-setenforce
> >  dist/install/usr/local/sbin/gdbsx
> >  dist/install/usr/local/sbin/gtracestat
> >  dist/install/usr/local/sbin/gtraceview
> > *** FILES DIFFER ***
> > 
> > On i686 and ARM* I only see the (expected) second hunk.
> > 
> > I think the i686 case is explainable by the lack of a hypervisor build
> > there, but I'm unsure why ARM* and x86_64 should differ in this regard.
> > 
> > config/Tools.mk is y only on x86_64, not on the others, which obviously
> > explains things, but the question is why only on x86_64 (I presume this
> > has
> > always been the case and it was previously masked, but I've not
> > checked).
> > 
> > Ah, OK, I misread
> > 
> > AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
> > 
> > as being default disable, actually the default is "enabled iff
> > checkpolicy
> > is installed" and it happens to be that it is only installed in my
> > x86_64
> > build env.
> > 
> > So, in the end I think Wei was correct and this change will now, in
> > some
> > circumstances, end up installing a /boot/xenpolicy-*.
> > 
> 
> I don't think it is related to this patch. I see an xenpoilcy file
> without this patch applied.

With XSM disabled?

>  As you said it only depends on availability
> of checkpolicy (part of generic SELinux utils, not the ones we build).

But then why does this file only show up for me with this patch applied?

You initially objected to this patch because you thought it would add this
file, but it seems like you have always had it. Is the answer just that you
only just found that you always had it?

> 
> That said, let me try to answer the following question.
> 
> > So the question is do we mind that?
> > 
> 
> We might or might not. See below.
> 
> I once submitted a patch to grub that look into /boot and generate XSM
> entries if there is policy file. The patch is not yet merged though.
> 
> Since there is no way at the moment to tell if xen.gz has flask enabled,
> my not yet upstreamed patch only matches the version number of xen.gz and
> xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
> make grub generate an XSM entry nonetheless, which makes no sense.

Indeed.

> Of course all the above is based on the theory that my grub patch is
> going to be upstreamed.
> 
> Things have changed since I first submitted that patch. Doug's Kconfig
> work is good. With .config installed in suitable location we can make
> grub grep for flask information in config, hence avoiding generating
> wrong entries.  I think this is better solution as we don't need to use
> version number to match xen.gz and xenpolicy. If we go down this route
> we don't mind having random xenpolicy lying around in /boot.

> We just need to reach an agreement on how to proceed. I would vote for
> the second solution.

Which is what? This patch as is? (and what is the first proposition?)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 4554 bytes --]

On 1/5/16 10:13 AM, Wei Liu wrote:
> On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
>> On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
>>>
>>> which on the basis of this discussion I wasn't expecting. I didn't see this
>>> new file on i686 or ARM*.
>>>
>>> My baseline is from the last time I committed, which would be last year, so
>>> maybe something other than my current batch of patches has caused this.
>>>
>>> I'm going to drop this one for now and (hopefully) get the rest of the
>>> batch squared away. Afterwards I'll take another look (with a new baseline
>>> filelist), but if someone can explain it in the meantime that would be
>>> super.
>>
>> So with a fresh basline I still see:
>>
>> --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000 +0000
>> +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
>> @@ -6,6 +6,7 @@
>>  dist/install/boot/xen-4.7-unstable.gz
>>  dist/install/boot/xen-4.gz
>>  dist/install/boot/xen.gz
>> +dist/install/boot/xenpolicy-4.7-unstable
>>  dist/install/etc
>>  dist/install/etc/bash_completion.d
>>  dist/install/etc/bash_completion.d/xl.sh
>> @@ -386,6 +387,12 @@
>>  dist/install/usr/local/lib/xen/libexec
>>  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
>>  dist/install/usr/local/sbin
>> +dist/install/usr/local/sbin/flask-get-bool
>> +dist/install/usr/local/sbin/flask-getenforce
>> +dist/install/usr/local/sbin/flask-label-pci
>> +dist/install/usr/local/sbin/flask-loadpolicy
>> +dist/install/usr/local/sbin/flask-set-bool
>> +dist/install/usr/local/sbin/flask-setenforce
>>  dist/install/usr/local/sbin/gdbsx
>>  dist/install/usr/local/sbin/gtracestat
>>  dist/install/usr/local/sbin/gtraceview
>> *** FILES DIFFER ***
>>
>> On i686 and ARM* I only see the (expected) second hunk.
>>
>> I think the i686 case is explainable by the lack of a hypervisor build
>> there, but I'm unsure why ARM* and x86_64 should differ in this regard.
>>
>> config/Tools.mk is y only on x86_64, not on the others, which obviously
>> explains things, but the question is why only on x86_64 (I presume this has
>> always been the case and it was previously masked, but I've not checked).
>>
>> Ah, OK, I misread
>>
>> AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
>>
>> as being default disable, actually the default is "enabled iff checkpolicy
>> is installed" and it happens to be that it is only installed in my x86_64
>> build env.
>>
>> So, in the end I think Wei was correct and this change will now, in some
>> circumstances, end up installing a /boot/xenpolicy-*.
>>
> 
> I don't think it is related to this patch. I see an xenpoilcy file
> without this patch applied. As you said it only depends on availability
> of checkpolicy (part of generic SELinux utils, not the ones we build).
> 
> That said, let me try to answer the following question.
> 
>> So the question is do we mind that?
>>
> 
> We might or might not. See below.
> 
> I once submitted a patch to grub that look into /boot and generate XSM
> entries if there is policy file. The patch is not yet merged though.
> 
> Since there is no way at the moment to tell if xen.gz has flask enabled,
> my not yet upstreamed patch only matches the version number of xen.gz and
> xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
> make grub generate an XSM entry nonetheless, which makes no sense.
> 
> Of course all the above is based on the theory that my grub patch is
> going to be upstreamed.
> 
> Things have changed since I first submitted that patch. Doug's Kconfig
> work is good. With .config installed in suitable location we can make
> grub grep for flask information in config, hence avoiding generating
> wrong entries.  I think this is better solution as we don't need to use
> version number to match xen.gz and xenpolicy. If we go down this route
> we don't mind having random xenpolicy lying around in /boot.

So I submitted a patch to put the .config in /boot to have the ability
to do this. I figured it needed to be in /boot because that's how the
existing 20_linux_xen but there's some disagreement on the location. If
we can resolve that I'll happily update the 20_linux_xen patch as well.

http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02369.html


> 
> We just need to reach an agreement on how to proceed. I would vote for
> the second solution.
> 
> Wei.
> 
> 
>> Ian.


-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Ian Campbell]

On Tue, 2016-01-05 at 10:34 -0600, Doug Goldstein wrote:
> On 1/5/16 10:13 AM, Wei Liu wrote:
> > On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
> > > On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
> > > > 
> > > > which on the basis of this discussion I wasn't expecting. I didn't
> > > > see this
> > > > new file on i686 or ARM*.
> > > > 
> > > > My baseline is from the last time I committed, which would be last
> > > > year, so
> > > > maybe something other than my current batch of patches has caused
> > > > this.
> > > > 
> > > > I'm going to drop this one for now and (hopefully) get the rest of
> > > > the
> > > > batch squared away. Afterwards I'll take another look (with a new
> > > > baseline
> > > > filelist), but if someone can explain it in the meantime that would
> > > > be
> > > > super.
> > > 
> > > So with a fresh basline I still see:
> > > 
> > > --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000
> > > +0000
> > > +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
> > > @@ -6,6 +6,7 @@
> > >  dist/install/boot/xen-4.7-unstable.gz
> > >  dist/install/boot/xen-4.gz
> > >  dist/install/boot/xen.gz
> > > +dist/install/boot/xenpolicy-4.7-unstable
> > >  dist/install/etc
> > >  dist/install/etc/bash_completion.d
> > >  dist/install/etc/bash_completion.d/xl.sh
> > > @@ -386,6 +387,12 @@
> > >  dist/install/usr/local/lib/xen/libexec
> > >  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
> > >  dist/install/usr/local/sbin
> > > +dist/install/usr/local/sbin/flask-get-bool
> > > +dist/install/usr/local/sbin/flask-getenforce
> > > +dist/install/usr/local/sbin/flask-label-pci
> > > +dist/install/usr/local/sbin/flask-loadpolicy
> > > +dist/install/usr/local/sbin/flask-set-bool
> > > +dist/install/usr/local/sbin/flask-setenforce
> > >  dist/install/usr/local/sbin/gdbsx
> > >  dist/install/usr/local/sbin/gtracestat
> > >  dist/install/usr/local/sbin/gtraceview
> > > *** FILES DIFFER ***
> > > 
> > > On i686 and ARM* I only see the (expected) second hunk.
> > > 
> > > I think the i686 case is explainable by the lack of a hypervisor
> > > build
> > > there, but I'm unsure why ARM* and x86_64 should differ in this
> > > regard.
> > > 
> > > config/Tools.mk is y only on x86_64, not on the others, which
> > > obviously
> > > explains things, but the question is why only on x86_64 (I presume
> > > this has
> > > always been the case and it was previously masked, but I've not
> > > checked).
> > > 
> > > Ah, OK, I misread
> > > 
> > > AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
> > > 
> > > as being default disable, actually the default is "enabled iff
> > > checkpolicy
> > > is installed" and it happens to be that it is only installed in my
> > > x86_64
> > > build env.
> > > 
> > > So, in the end I think Wei was correct and this change will now, in
> > > some
> > > circumstances, end up installing a /boot/xenpolicy-*.
> > > 
> > 
> > I don't think it is related to this patch. I see an xenpoilcy file
> > without this patch applied. As you said it only depends on availability
> > of checkpolicy (part of generic SELinux utils, not the ones we build).
> > 
> > That said, let me try to answer the following question.
> > 
> > > So the question is do we mind that?
> > > 
> > 
> > We might or might not. See below.
> > 
> > I once submitted a patch to grub that look into /boot and generate XSM
> > entries if there is policy file. The patch is not yet merged though.
> > 
> > Since there is no way at the moment to tell if xen.gz has flask
> > enabled,
> > my not yet upstreamed patch only matches the version number of xen.gz
> > and
> > xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
> > make grub generate an XSM entry nonetheless, which makes no sense.
> > 
> > Of course all the above is based on the theory that my grub patch is
> > going to be upstreamed.
> > 
> > Things have changed since I first submitted that patch. Doug's Kconfig
> > work is good. With .config installed in suitable location we can make
> > grub grep for flask information in config, hence avoiding generating
> > wrong entries.  I think this is better solution as we don't need to use
> > version number to match xen.gz and xenpolicy. If we go down this route
> > we don't mind having random xenpolicy lying around in /boot.
> 
> So I submitted a patch to put the .config in /boot to have the ability
> to do this. I figured it needed to be in /boot because that's how the
> existing 20_linux_xen but there's some disagreement on the location. If
> we can resolve that I'll happily update the 20_linux_xen patch as well.
> 
> http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02369.html

It would be worth referring that thread back to this one too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Tue, Jan 05, 2016 at 04:24:19PM +0000, Ian Campbell wrote:
> On Tue, 2016-01-05 at 16:13 +0000, Wei Liu wrote:
> > On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
> > > On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
> > > > 
> > > > which on the basis of this discussion I wasn't expecting. I didn't
> > > > see this
> > > > new file on i686 or ARM*.
> > > > 
> > > > My baseline is from the last time I committed, which would be last
> > > > year, so
> > > > maybe something other than my current batch of patches has caused
> > > > this.
> > > > 
> > > > I'm going to drop this one for now and (hopefully) get the rest of
> > > > the
> > > > batch squared away. Afterwards I'll take another look (with a new
> > > > baseline
> > > > filelist), but if someone can explain it in the meantime that would
> > > > be
> > > > super.
> > > 
> > > So with a fresh basline I still see:
> > > 
> > > --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000
> > > +0000
> > > +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
> > > @@ -6,6 +6,7 @@
> > >  dist/install/boot/xen-4.7-unstable.gz
> > >  dist/install/boot/xen-4.gz
> > >  dist/install/boot/xen.gz
> > > +dist/install/boot/xenpolicy-4.7-unstable
> > >  dist/install/etc
> > >  dist/install/etc/bash_completion.d
> > >  dist/install/etc/bash_completion.d/xl.sh
> > > @@ -386,6 +387,12 @@
> > >  dist/install/usr/local/lib/xen/libexec
> > >  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
> > >  dist/install/usr/local/sbin
> > > +dist/install/usr/local/sbin/flask-get-bool
> > > +dist/install/usr/local/sbin/flask-getenforce
> > > +dist/install/usr/local/sbin/flask-label-pci
> > > +dist/install/usr/local/sbin/flask-loadpolicy
> > > +dist/install/usr/local/sbin/flask-set-bool
> > > +dist/install/usr/local/sbin/flask-setenforce
> > >  dist/install/usr/local/sbin/gdbsx
> > >  dist/install/usr/local/sbin/gtracestat
> > >  dist/install/usr/local/sbin/gtraceview
> > > *** FILES DIFFER ***
> > > 
> > > On i686 and ARM* I only see the (expected) second hunk.
> > > 
> > > I think the i686 case is explainable by the lack of a hypervisor build
> > > there, but I'm unsure why ARM* and x86_64 should differ in this regard.
> > > 
> > > config/Tools.mk is y only on x86_64, not on the others, which obviously
> > > explains things, but the question is why only on x86_64 (I presume this
> > > has
> > > always been the case and it was previously masked, but I've not
> > > checked).
> > > 
> > > Ah, OK, I misread
> > > 
> > > AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
> > > 
> > > as being default disable, actually the default is "enabled iff
> > > checkpolicy
> > > is installed" and it happens to be that it is only installed in my
> > > x86_64
> > > build env.
> > > 
> > > So, in the end I think Wei was correct and this change will now, in
> > > some
> > > circumstances, end up installing a /boot/xenpolicy-*.
> > > 
> > 
> > I don't think it is related to this patch. I see an xenpoilcy file
> > without this patch applied.
> 
> With XSM disabled?
> 
> >  As you said it only depends on availability
> > of checkpolicy (part of generic SELinux utils, not the ones we build).
> 
> But then why does this file only show up for me with this patch applied?
> 
> You initially objected to this patch because you thought it would add this
> file, but it seems like you have always had it. Is the answer just that you
> only just found that you always had it?
> 

Hmm... After I make distclean, things changed.

So to be clear: without this patch applied, I don't have xenpolicy file
even if checkpolicy is available. This patch does alter the behaviour
somehow.

I'm in the middle of rebasing one patch series,  so I haven't looked
into all the details.

> > 
> > That said, let me try to answer the following question.
> > 
> > > So the question is do we mind that?
> > > 
> > 
> > We might or might not. See below.
> > 
> > I once submitted a patch to grub that look into /boot and generate XSM
> > entries if there is policy file. The patch is not yet merged though.
> > 
> > Since there is no way at the moment to tell if xen.gz has flask enabled,
> > my not yet upstreamed patch only matches the version number of xen.gz and
> > xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
> > make grub generate an XSM entry nonetheless, which makes no sense.
> 
> Indeed.
> 
> > Of course all the above is based on the theory that my grub patch is
> > going to be upstreamed.
> > 
> > Things have changed since I first submitted that patch. Doug's Kconfig
> > work is good. With .config installed in suitable location we can make
> > grub grep for flask information in config, hence avoiding generating
> > wrong entries.  I think this is better solution as we don't need to use
> > version number to match xen.gz and xenpolicy. If we go down this route
> > we don't mind having random xenpolicy lying around in /boot.
> 
> > We just need to reach an agreement on how to proceed. I would vote for
> > the second solution.
> 
> Which is what? This patch as is? (and what is the first proposition?)
> 

That was referring to grub generating XSM entries. First solution is my
not yet upstream patch; second is to make gurb grep .config for flask
information.

Wei.

> Ian.

Re: [PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 6053 bytes --]

On 1/5/16 10:42 AM, Wei Liu wrote:
> On Tue, Jan 05, 2016 at 04:24:19PM +0000, Ian Campbell wrote:
>> On Tue, 2016-01-05 at 16:13 +0000, Wei Liu wrote:
>>> On Tue, Jan 05, 2016 at 03:36:21PM +0000, Ian Campbell wrote:
>>>> On Tue, 2016-01-05 at 14:37 +0000, Ian Campbell wrote:
>>>>>
>>>>> which on the basis of this discussion I wasn't expecting. I didn't
>>>>> see this
>>>>> new file on i686 or ARM*.
>>>>>
>>>>> My baseline is from the last time I committed, which would be last
>>>>> year, so
>>>>> maybe something other than my current batch of patches has caused
>>>>> this.
>>>>>
>>>>> I'm going to drop this one for now and (hopefully) get the rest of
>>>>> the
>>>>> batch squared away. Afterwards I'll take another look (with a new
>>>>> baseline
>>>>> filelist), but if someone can explain it in the meantime that would
>>>>> be
>>>>> super.
>>>>
>>>> So with a fresh basline I still see:
>>>>
>>>> --- ../FILE_LIST.BASE.staging.x86_64    2016-01-05 14:50:32.000000000
>>>> +0000
>>>> +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.000000000 +0000
>>>> @@ -6,6 +6,7 @@
>>>>  dist/install/boot/xen-4.7-unstable.gz
>>>>  dist/install/boot/xen-4.gz
>>>>  dist/install/boot/xen.gz
>>>> +dist/install/boot/xenpolicy-4.7-unstable
>>>>  dist/install/etc
>>>>  dist/install/etc/bash_completion.d
>>>>  dist/install/etc/bash_completion.d/xl.sh
>>>> @@ -386,6 +387,12 @@
>>>>  dist/install/usr/local/lib/xen/libexec
>>>>  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
>>>>  dist/install/usr/local/sbin
>>>> +dist/install/usr/local/sbin/flask-get-bool
>>>> +dist/install/usr/local/sbin/flask-getenforce
>>>> +dist/install/usr/local/sbin/flask-label-pci
>>>> +dist/install/usr/local/sbin/flask-loadpolicy
>>>> +dist/install/usr/local/sbin/flask-set-bool
>>>> +dist/install/usr/local/sbin/flask-setenforce
>>>>  dist/install/usr/local/sbin/gdbsx
>>>>  dist/install/usr/local/sbin/gtracestat
>>>>  dist/install/usr/local/sbin/gtraceview
>>>> *** FILES DIFFER ***
>>>>
>>>> On i686 and ARM* I only see the (expected) second hunk.
>>>>
>>>> I think the i686 case is explainable by the lack of a hypervisor build
>>>> there, but I'm unsure why ARM* and x86_64 should differ in this regard.
>>>>
>>>> config/Tools.mk is y only on x86_64, not on the others, which obviously
>>>> explains things, but the question is why only on x86_64 (I presume this
>>>> has
>>>> always been the case and it was previously masked, but I've not
>>>> checked).
>>>>
>>>> Ah, OK, I misread
>>>>
>>>> AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
>>>>
>>>> as being default disable, actually the default is "enabled iff
>>>> checkpolicy
>>>> is installed" and it happens to be that it is only installed in my
>>>> x86_64
>>>> build env.
>>>>
>>>> So, in the end I think Wei was correct and this change will now, in
>>>> some
>>>> circumstances, end up installing a /boot/xenpolicy-*.
>>>>
>>>
>>> I don't think it is related to this patch. I see an xenpoilcy file
>>> without this patch applied.
>>
>> With XSM disabled?
>>
>>>  As you said it only depends on availability
>>> of checkpolicy (part of generic SELinux utils, not the ones we build).
>>
>> But then why does this file only show up for me with this patch applied?
>>
>> You initially objected to this patch because you thought it would add this
>> file, but it seems like you have always had it. Is the answer just that you
>> only just found that you always had it?
>>
> 
> Hmm... After I make distclean, things changed.
> 
> So to be clear: without this patch applied, I don't have xenpolicy file
> even if checkpolicy is available. This patch does alter the behaviour
> somehow.
> 
> I'm in the middle of rebasing one patch series,  so I haven't looked
> into all the details.
> 
>>>
>>> That said, let me try to answer the following question.
>>>
>>>> So the question is do we mind that?
>>>>
>>>
>>> We might or might not. See below.
>>>
>>> I once submitted a patch to grub that look into /boot and generate XSM
>>> entries if there is policy file. The patch is not yet merged though.
>>>
>>> Since there is no way at the moment to tell if xen.gz has flask enabled,
>>> my not yet upstreamed patch only matches the version number of xen.gz and
>>> xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
>>> make grub generate an XSM entry nonetheless, which makes no sense.
>>
>> Indeed.
>>
>>> Of course all the above is based on the theory that my grub patch is
>>> going to be upstreamed.
>>>
>>> Things have changed since I first submitted that patch. Doug's Kconfig
>>> work is good. With .config installed in suitable location we can make
>>> grub grep for flask information in config, hence avoiding generating
>>> wrong entries.  I think this is better solution as we don't need to use
>>> version number to match xen.gz and xenpolicy. If we go down this route
>>> we don't mind having random xenpolicy lying around in /boot.
>>
>>> We just need to reach an agreement on how to proceed. I would vote for
>>> the second solution.
>>
>> Which is what? This patch as is? (and what is the first proposition?)
>>
> 
> That was referring to grub generating XSM entries. First solution is my
> not yet upstream patch; second is to make gurb grep .config for flask
> information.
> 
> Wei.
> 
>> Ian.

Ok so I'm at a loss what steps I need to take. I've submitted patches to
put the config in /boot so that this check can be made but there's a
disagreement if that's even necessary or not.

Do I need to supply a patch to make --disable-xsmpolicy the default so
that this change doesn't generate the policy by default? The point of
this patch is to compile the necessarily bits always which will help
shake out bugs earlier. If we don't want the policy file to be installed
then we should use the proper setting for that and not the fact that the
utility isn't being compiled.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 2/2] xen: convert XSM_ENABLE to Kconfig

[Ian Jackson]

Doug Goldstein writes ("[Xen-devel] [PATCH v2 2/2] xen: convert XSM_ENABLE to Kconfig"):
> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
> CONFIG_XSM.

Some version of these patches were applied to xen.git#staging last
week as:
  b36bf230 "convert FLASK_ENABLE to Kconfig"
  2b2ab5d8 "convert XSM_ENABLE to Kconfig"
  9754544a "fix missing XSM_ENABLE change"

They made it through to xen.git#smoke.  However, osstest was not
ready, so that old osstest would generate non-XSM tests when it
intended to test XSM.  To avoid XSM-related regressions sneaking in,
these patches were referted in xen.git [1].

The corresponding osstest.git change, which is (we think) compatible
with both old and new xen.git, has now made it through the osstest
self-push-gate.

We can reapply the xen.git XSM/FLASK Kconfig patches now.  We should
check the first test report on a xen-unstable containing the
reapplication, to verify that XSM is actually enabled in the XSM
tests.


For the future, it would be really good if the osstest XSM tests
attempted some forbidden operations and verified that they failed.  If
we had that at the start of all this then the config
regression/incompatibility would have been caught by those tests.

Such patches to osstest would be very welcome and I'd be happy to
help.

Thanks,
Ian.

[1] Also, the osstest push gate from xen.git#smoke to xen.git#master
was stopped.  Since the xen.git reverts have made it to #smoke it is
now fine to restart the xen.git#smoke to xen.git#master push gate.

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
[...]
> Ok so I'm at a loss what steps I need to take. I've submitted patches to
> put the config in /boot so that this check can be made but there's a
> disagreement if that's even necessary or not.
> 

That's a bit unfortunate. :-(

But if I'm not mistaken that's orthogonal to this problem, right? That's
one more step down the road regarding grub integration.

> Do I need to supply a patch to make --disable-xsmpolicy the default so
> that this change doesn't generate the policy by default? The point of
> this patch is to compile the necessarily bits always which will help
> shake out bugs earlier. If we don't want the policy file to be installed
> then we should use the proper setting for that and not the fact that the
> utility isn't being compiled.
> 

I think one solution would be to modify flask/Makefile to guard policy
compilation against (FLASK_ENABLE && FLASK_POLICY).

What do you think? Admittedly I haven't followed closely all the KConfig
work so I might be talking nonsense.

Ian and Ian?

Wei.

> -- 
> Doug Goldstein
> 

Re: [PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1806 bytes --]

On 1/11/16 9:19 AM, Wei Liu wrote:
> On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
> [...]
>> Ok so I'm at a loss what steps I need to take. I've submitted patches to
>> put the config in /boot so that this check can be made but there's a
>> disagreement if that's even necessary or not.
>>
> 
> That's a bit unfortunate. :-(
> 
> But if I'm not mistaken that's orthogonal to this problem, right? That's
> one more step down the road regarding grub integration.
> 
>> Do I need to supply a patch to make --disable-xsmpolicy the default so
>> that this change doesn't generate the policy by default? The point of
>> this patch is to compile the necessarily bits always which will help
>> shake out bugs earlier. If we don't want the policy file to be installed
>> then we should use the proper setting for that and not the fact that the
>> utility isn't being compiled.
>>
> 
> I think one solution would be to modify flask/Makefile to guard policy
> compilation against (FLASK_ENABLE && FLASK_POLICY).
> 
> What do you think? Admittedly I haven't followed closely all the KConfig
> work so I might be talking nonsense.
> 
> Ian and Ian?
> 
> Wei.

Wei (and Ian and Ian and Daniel),

There's already a guard against compiling the policy in the tools/
directory's configure script called --{enable,disable}-xsmpolicy What I
could do is disable it by default because it is currently enabled by
default.

I honestly think that would be an improvement because we would compile
all the source code (causing us to shake bugs out earlier) but only
generate the policy when the user explicitly requests it. Right now the
policy is made whenever the utilities are compiled.

Let me know if that sounds appealing to you.

Thanks.
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Mon, Jan 11, 2016 at 11:10:35AM -0600, Doug Goldstein wrote:
> On 1/11/16 9:19 AM, Wei Liu wrote:
> > On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
> > [...]
> >> Ok so I'm at a loss what steps I need to take. I've submitted patches to
> >> put the config in /boot so that this check can be made but there's a
> >> disagreement if that's even necessary or not.
> >>
> > 
> > That's a bit unfortunate. :-(
> > 
> > But if I'm not mistaken that's orthogonal to this problem, right? That's
> > one more step down the road regarding grub integration.
> > 
> >> Do I need to supply a patch to make --disable-xsmpolicy the default so
> >> that this change doesn't generate the policy by default? The point of
> >> this patch is to compile the necessarily bits always which will help
> >> shake out bugs earlier. If we don't want the policy file to be installed
> >> then we should use the proper setting for that and not the fact that the
> >> utility isn't being compiled.
> >>
> > 
> > I think one solution would be to modify flask/Makefile to guard policy
> > compilation against (FLASK_ENABLE && FLASK_POLICY).
> > 
> > What do you think? Admittedly I haven't followed closely all the KConfig
> > work so I might be talking nonsense.
> > 
> > Ian and Ian?
> > 
> > Wei.
> 
> Wei (and Ian and Ian and Daniel),
> 
> There's already a guard against compiling the policy in the tools/
> directory's configure script called --{enable,disable}-xsmpolicy What I
> could do is disable it by default because it is currently enabled by
> default.
> 
> I honestly think that would be an improvement because we would compile
> all the source code (causing us to shake bugs out earlier) but only
> generate the policy when the user explicitly requests it. Right now the
> policy is made whenever the utilities are compiled.
> 
> Let me know if that sounds appealing to you.
> 

Fine by me.

I don't really have a strong opinion at this point. My original concern
that the installed xenpolicy file interferes with grub was based on the
assumption that we only had version numbers as indicator to match
hypervisor binary and xenpolicy file. But now since I think there is
better way to generate grub entry I don't think my objection based on
the (bad) assumption to this patch is relevant anymore.

Wei.

> Thanks.
> -- 
> Doug Goldstein
> 

Re: [PATCH] tools: make FLASK utils build unconditional

[Ian Campbell]

On Fri, 2016-01-15 at 19:48 +0000, Andrew Cooper wrote:
> On 15/01/16 17:39, Doug Goldstein wrote:
> > The flask utilities only have dependencies on libxc so there's no
> > downside to always building it. Distros and projects based on Xen can
> > put these in a different package to not install them for all users.
> > Prior to this change FLASK_ENABLE needed to be set at the top level to
> > build the utilities and the tools/configure script would build the
> > FLASK
> > policy by default, but only if the utilities were built.
> > 
> > This change makes item 3 from
> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.ht
> > ml
> > a happen by default.
> > 
> > CC: Ian Jackson <ian.jackson@eu.citrix.com>
> > CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Ian Campbell <ian.campbell@citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

As noted elsewhere I have acked + applied htis.

Re: [PATCH] tools: make FLASK utils build unconditional

[Andrew Cooper]

On 15/01/16 17:39, Doug Goldstein wrote:
> The flask utilities only have dependencies on libxc so there's no
> downside to always building it. Distros and projects based on Xen can
> put these in a different package to not install them for all users.
> Prior to this change FLASK_ENABLE needed to be set at the top level to
> build the utilities and the tools/configure script would build the FLASK
> policy by default, but only if the utilities were built.
>
> This change makes item 3 from
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html
> a happen by default.
>
> CC: Ian Jackson <ian.jackson@eu.citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  tools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f74ac7..3f9289b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -5,7 +5,7 @@ SUBDIRS-y :=
>  SUBDIRS-y += include
>  SUBDIRS-y += libs
>  SUBDIRS-y += libxc
> -SUBDIRS-$(FLASK_ENABLE) += flask
> +SUBDIRS-y += flask
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples

[PATCH] tools: make FLASK utils build unconditional

[Doug Goldstein]

The flask utilities only have dependencies on libxc so there's no
downside to always building it. Distros and projects based on Xen can
put these in a different package to not install them for all users.
Prior to this change FLASK_ENABLE needed to be set at the top level to
build the utilities and the tools/configure script would build the FLASK
policy by default, but only if the utilities were built.

This change makes item 3 from
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html
a happen by default.

CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9f74ac7..3f9289b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -5,7 +5,7 @@ SUBDIRS-y :=
 SUBDIRS-y += include
 SUBDIRS-y += libs
 SUBDIRS-y += libxc
-SUBDIRS-$(FLASK_ENABLE) += flask
+SUBDIRS-y += flask
 SUBDIRS-y += xenstore
 SUBDIRS-y += misc
 SUBDIRS-y += examples
-- 
2.4.10