[PATCH v1 0/2] XSM labels support in dom0less

[PATCH v1 0/2] XSM labels support in dom0less

[Sergiy Kibrik]

Currently FLASK can't really be enforced for domains being brought up in
dom0less mode, as security contexts are not assigned for domains in this
configuration. Thus domains are left with default SECINITSID_UNLABELED SID
which policy forbids to create:

    (XEN) [    0.637379] avc:  denied  { create } for current=d[IDLE] scontext=system_u:system_r:xenboot_t tcontext=system_u:system_r:unlabeled_t tclass=domain

This series extends dom0less bindings with ability to provide human-readable
security context in domain's DTS configuration, replicating a toolstack
approach and naming.

 -Sergiy

Sergiy Kibrik (2):
  flask: add const qualifier to security_context_to_sid()
  common: dom0less-bindings: introduce XSM labels

 docs/misc/arm/device-tree/booting.txt      |  8 ++++++++
 xen/common/device-tree/Makefile            |  2 ++
 xen/common/device-tree/dom0less-bindings.c | 11 +++++++++++
 xen/xsm/flask/include/security.h           |  2 +-
 xen/xsm/flask/ss/services.c                |  2 +-
 5 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH v1 1/2] flask: add const qualifier to security_context_to_sid()

[Sergiy Kibrik]

The function does not modify context argument.
Also it gives more flexibility to this API usage, because some context strings
in Xen are also const char*.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
 xen/xsm/flask/include/security.h | 2 +-
 xen/xsm/flask/ss/services.c      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index ec8b442a8f..a2c5f423f8 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -76,7 +76,7 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid);
 
 int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
 
-int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
+int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *out_sid);
 
 int security_get_allow_unknown(void);
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 35ad1034ca..764ac7d1d8 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -813,7 +813,7 @@ out:
  * Returns -%EINVAL if the context is invalid, -%ENOMEM if insufficient
  * memory is available, or 0 on success.
  */
-int security_context_to_sid(char *scontext, u32 scontext_len, u32 *sid)
+int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *sid)
 {
     char *scontext2;
     struct context context;
-- 
2.43.0

Re: [PATCH v1 1/2] flask: add const qualifier to security_context_to_sid()

[Daniel P. Smith]

On 8/27/26 5:38 AM, Sergiy Kibrik wrote:
> The function does not modify context argument.
> Also it gives more flexibility to this API usage, because some context strings
> in Xen are also const char*.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>   xen/xsm/flask/include/security.h | 2 +-
>   xen/xsm/flask/ss/services.c      | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
> index ec8b442a8f..a2c5f423f8 100644
> --- a/xen/xsm/flask/include/security.h
> +++ b/xen/xsm/flask/include/security.h
> @@ -76,7 +76,7 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid);
>   
>   int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
>   
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *out_sid);
>   
>   int security_get_allow_unknown(void);
>   
> diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
> index 35ad1034ca..764ac7d1d8 100644
> --- a/xen/xsm/flask/ss/services.c
> +++ b/xen/xsm/flask/ss/services.c
> @@ -813,7 +813,7 @@ out:
>    * Returns -%EINVAL if the context is invalid, -%ENOMEM if insufficient
>    * memory is available, or 0 on success.
>    */
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *sid)
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *sid)
>   {
>       char *scontext2;
>       struct context context;

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Re: [PATCH v1 1/2] flask: add const qualifier to security_context_to_sid()

[Jan Beulich]

On 27.08.2026 11:38, Sergiy Kibrik wrote:
> --- a/xen/xsm/flask/include/security.h
> +++ b/xen/xsm/flask/include/security.h
> @@ -76,7 +76,7 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid);
>  
>  int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
>  
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *out_sid);

I see Daniel has ack-ed this, but:
- The line is too long now.
- The last parameter name here doesn't match that of the definition.
- While touching code anyway, it would be nice if u<N> was converted to
  uint<N>_t (or else we'll never complete that conversion).
I think I'll take the liberty of addressing all of these while committing.

Jan

Re: [PATCH v1 1/2] flask: add const qualifier to security_context_to_sid()

[Sergiy Kibrik]

On 8/28/26 09:40, Jan Beulich wrote:
> - While touching code anyway, it would be nice if u<N> was converted to
>    uint<N>_t (or else we'll never complete that conversion).
> I think I'll take the liberty of addressing all of these while committing.

thank you, Jan. BTW, what's up with u<N>? Are they expected to be 
dropped/converted in Xen?

   -Sergiy

Re: [PATCH v1 1/2] flask: add const qualifier to security_context_to_sid()

[Jan Beulich]

On 31.08.2026 12:01, Sergiy Kibrik wrote:
> On 8/28/26 09:40, Jan Beulich wrote:
>> - While touching code anyway, it would be nice if u<N> was converted to
>>    uint<N>_t (or else we'll never complete that conversion).
>> I think I'll take the liberty of addressing all of these while committing.
> 
> thank you, Jan. BTW, what's up with u<N>? Are they expected to be 
> dropped/converted in Xen?

Yes. If you go look, s<N> were already dropped, as were __[su]<N>. The use
of u<N> sadly is far more widespread.

Jan

[PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels

[Sergiy Kibrik]

Add "seclabel" property to be able to specify security label for a domain
when XSM Flask is enabled, similar to xl configuration files.

Currently guest domain can't be created by Xen in dom0less configuration when
Flask is enabled, as domain is assigned "system_u:system_r:unlabeled_t" label
by default, which Flask denies to create according to current policy.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
 docs/misc/arm/device-tree/booting.txt      |  8 ++++++++
 xen/common/device-tree/Makefile            |  2 ++
 xen/common/device-tree/dom0less-bindings.c | 11 +++++++++++
 3 files changed, 21 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index bcb06bc796..fcc7be0ffb 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -345,6 +345,12 @@ with the following properties:
     not passed. This configuration requires static allocation (xen,static-mem)
     and direct mapping (direct-map).
 
+- seclabel
+
+    A string property specifying an XSM security label to this domain. Effective
+    only when FLASK is enabled. Domains will be classified “unlabeled” if
+    this property not specified.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
 
@@ -422,6 +428,7 @@ chosen {
         memory = <0 131072>;
         cpus = <2>;
         vpl011;
+        seclabel = "system_u:system_r:domU_t";
 
         vcpu0 {
             compatible = "xen,vcpu";
@@ -453,6 +460,7 @@ chosen {
         #size-cells = <0x1>;
         memory = <0 65536>;
         cpus = <1>;
+        seclabel = "system_u:system_r:domU_t";
 
         module@0x4c000000 {
             compatible = "multiboot,kernel", "multiboot,module";
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 9036e455d6..e4de292533 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
+
+CFLAGS-y += -I$(srctree)/xsm/flask/include
diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c
index 41d72d0d58..bffd2ec65d 100644
--- a/xen/common/device-tree/dom0less-bindings.c
+++ b/xen/common/device-tree/dom0less-bindings.c
@@ -11,6 +11,8 @@
 #include <public/bootfdt.h>
 #include <public/domctl.h>
 
+#include <security.h>
+
 int __init parse_dom0less_node(struct dt_device_node *node,
                                struct boot_domain *bd)
 {
@@ -21,6 +23,7 @@ int __init parse_dom0less_node(struct dt_device_node *node,
     bool has_dtb = false;
     bool iommu = false;
     const char *dom0less_iommu = NULL;
+    const char *xsm_seclabel = NULL;
 
     if ( !dt_device_is_compatible(node, "xen,domain") )
         return -ENOENT;
@@ -141,5 +144,13 @@ int __init parse_dom0less_node(struct dt_device_node *node,
         panic("'llc-colors' found, but LLC coloring is disabled\n");
 #endif
 
+    if ( IS_ENABLED(CONFIG_XSM_FLASK) &&
+         !dt_property_read_string(node, "seclabel", &xsm_seclabel) )
+    {
+        if ( security_context_to_sid(xsm_seclabel, strlen(xsm_seclabel),
+                                     &d_cfg->ssidref) )
+            panic("Invalid security context for domain: %s\n", xsm_seclabel);
+    }
+
     return arch_parse_dom0less_node(node, bd);
 }
-- 
2.43.0

Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels

[Daniel P. Smith]

On 8/27/26 5:38 AM, Sergiy Kibrik wrote:
> Add "seclabel" property to be able to specify security label for a domain
> when XSM Flask is enabled, similar to xl configuration files.
> 
> Currently guest domain can't be created by Xen in dom0less configuration when
> Flask is enabled, as domain is assigned "system_u:system_r:unlabeled_t" label
> by default, which Flask denies to create according to current policy.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>   docs/misc/arm/device-tree/booting.txt      |  8 ++++++++
>   xen/common/device-tree/Makefile            |  2 ++
>   xen/common/device-tree/dom0less-bindings.c | 11 +++++++++++
>   3 files changed, 21 insertions(+)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index bcb06bc796..fcc7be0ffb 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -345,6 +345,12 @@ with the following properties:
>       not passed. This configuration requires static allocation (xen,static-mem)
>       and direct mapping (direct-map).
>   
> +- seclabel
> +
> +    A string property specifying an XSM security label to this domain. Effective
> +    only when FLASK is enabled. Domains will be classified “unlabeled” if
> +    this property not specified.
> +
>   Under the "xen,domain" compatible node, one or more sub-nodes are present
>   for the DomU kernel and ramdisk.
>   
> @@ -422,6 +428,7 @@ chosen {
>           memory = <0 131072>;
>           cpus = <2>;
>           vpl011;
> +        seclabel = "system_u:system_r:domU_t";
>   
>           vcpu0 {
>               compatible = "xen,vcpu";
> @@ -453,6 +460,7 @@ chosen {
>           #size-cells = <0x1>;
>           memory = <0 65536>;
>           cpus = <1>;
> +        seclabel = "system_u:system_r:domU_t";
>   
>           module@0x4c000000 {
>               compatible = "multiboot,kernel", "multiboot,module";
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 9036e455d6..e4de292533 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -11,3 +11,5 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>   obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>   obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
>   obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
> +
> +CFLAGS-y += -I$(srctree)/xsm/flask/include
> diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c
> index 41d72d0d58..bffd2ec65d 100644
> --- a/xen/common/device-tree/dom0less-bindings.c
> +++ b/xen/common/device-tree/dom0less-bindings.c
> @@ -11,6 +11,8 @@
>   #include <public/bootfdt.h>
>   #include <public/domctl.h>
>   
> +#include <security.h>
> +
>   int __init parse_dom0less_node(struct dt_device_node *node,
>                                  struct boot_domain *bd)
>   {
> @@ -21,6 +23,7 @@ int __init parse_dom0less_node(struct dt_device_node *node,
>       bool has_dtb = false;
>       bool iommu = false;
>       const char *dom0less_iommu = NULL;
> +    const char *xsm_seclabel = NULL;
>   
>       if ( !dt_device_is_compatible(node, "xen,domain") )
>           return -ENOENT;
> @@ -141,5 +144,13 @@ int __init parse_dom0less_node(struct dt_device_node *node,
>           panic("'llc-colors' found, but LLC coloring is disabled\n");
>   #endif
>   
> +    if ( IS_ENABLED(CONFIG_XSM_FLASK) &&
> +         !dt_property_read_string(node, "seclabel", &xsm_seclabel) )
> +    {
> +        if ( security_context_to_sid(xsm_seclabel, strlen(xsm_seclabel),
> +                                     &d_cfg->ssidref) )
> +            panic("Invalid security context for domain: %s\n", xsm_seclabel);
> +    }
> +
>       return arch_parse_dom0less_node(node, bd);
>   }

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels

[Andrew Cooper]

On 27/08/2026 10:38 am, Sergiy Kibrik wrote:
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 9036e455d6..e4de292533 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -11,3 +11,5 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>  obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>  obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
>  obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
> +
> +CFLAGS-y += -I$(srctree)/xsm/flask/include
> diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c
> index 41d72d0d58..bffd2ec65d 100644
> --- a/xen/common/device-tree/dom0less-bindings.c
> +++ b/xen/common/device-tree/dom0less-bindings.c
> @@ -11,6 +11,8 @@
>  #include <public/bootfdt.h>
>  #include <public/domctl.h>
>  
> +#include <security.h>
> +

security.h is a private header for internals of flask.  Requiring the
CFLAGS += -I should have been a hint.

If a suitable public function doesn't exist, then make one rather than
inserting a layering violation.

To this specifically, I'm not sure security_context_to_sid() handing out
SECINITSID_XEN if you happen to call it too early is the wisest
behaviour.  It's current call-chain has an earlier check which I think
excludes this from occurring.

~Andrew

Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels

[Sergiy Kibrik]

On 8/31/26 13:19, Andrew Cooper wrote:
> To this specifically, I'm not sure security_context_to_sid() handing out
> SECINITSID_XEN if you happen to call it too early is the wisest
> behaviour.  It's current call-chain has an earlier check which I think
> excludes this from occurring.

It's only call-chain is in FLASK_CONTEXT_TO_SID xsm_op handling, and it 
does return SECINITSID_XEN to toolstack if called before policy is 
loaded (I've tried booting with flask=late).

But what's the point of falling back to SECINITSID_XEN anyway?

  -Sergiy