Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of user, role
and type there can be, and is dependant on the policy being used.
Since the policy is generally not known in advance the size of sidtable in Xen
has a rather high limit of UINT_MAX entries.

However in the embedded environment configured for safety it is desirable to
avoid guest-triggered dynamic memory allocations at runtime, or at least limit
them to some decent and predictable amounts. This patch provides a configuration
option to impose such a limit.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
CC: Jan Beulich <jbeulich@suse.com>
---
After RFC patch discussion it's been suggested to use Kconfig option
instead of estimation of sidtable size at build time:

   https://lore.kernel.org/xen-devel/20250630085559.554334-1-Sergiy_Kibrik@epam.com/

 -Sergiy
---
 xen/common/Kconfig        | 19 +++++++++++++++++++
 xen/xsm/flask/ss/sidtab.c |  8 +++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f..f956a93fb3 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -418,6 +418,25 @@ config XSM_FLASK_AVC_STATS
 
 	  If unsure, say Y.
 
+config XSM_FLASK_SIDTABLE_LIMIT
+	def_bool n
+	prompt "Limit the size of SID table" if EXPERT
+	depends on XSM_FLASK
+	---help---
+	  Limit the number of security identifiers allocated and operated by Xen.
+	  This will limit the number of security contexts and heap memory
+	  allocated for SID table entries.
+
+	  If unsure, say N.
+
+config XSM_FLASK_MAX_SID
+	int "Max SID table size" if XSM_FLASK_SIDTABLE_LIMIT
+	default 512
+	help
+	  The maximum amount of SIDs allocated by Xen. Default value is
+	  approximately double the size of contexts that default Xen policy can
+	  potentially have.
+
 config XSM_FLASK_POLICY
 	bool "Compile Xen with a built-in FLASK security policy"
 	default y if "$(XEN_HAS_CHECKPOLICY)" = "y"
diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c
index 69fc3389b3..1dd0700b8c 100644
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -14,6 +14,12 @@
 #include "security.h"
 #include "sidtab.h"
 
+#ifdef CONFIG_XSM_FLASK_SIDTABLE_LIMIT
+#define SID_LIMIT CONFIG_XSM_FLASK_MAX_SID
+#else
+#define SID_LIMIT UINT_MAX
+#endif
+
 #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK)
 
 #define INIT_SIDTAB_LOCK(s) spin_lock_init(&(s)->lock)
@@ -228,7 +234,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context,
         if ( sid )
             goto unlock_out;
         /* No SID exists for the context.  Allocate a new one. */
-        if ( s->next_sid == UINT_MAX || s->shutdown )
+        if ( s->next_sid == SID_LIMIT || s->shutdown )
         {
             ret = -ENOMEM;
             goto unlock_out;
-- 
2.25.1

On 22.08.2025 11:51, Sergiy Kibrik wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig

I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
file there.

> @@ -418,6 +418,25 @@ config XSM_FLASK_AVC_STATS
>  
>  	  If unsure, say Y.
>  
> +config XSM_FLASK_SIDTABLE_LIMIT
> +	def_bool n

This makes little sense; just "bool" would have the same effect. Yet then
you can combine that with ...

> +	prompt "Limit the size of SID table" if EXPERT

... this line.

> +	depends on XSM_FLASK
> +	---help---

No triple dashes around "help" anymore, please.

> +	  Limit the number of security identifiers allocated and operated by Xen.
> +	  This will limit the number of security contexts and heap memory
> +	  allocated for SID table entries.
> +
> +	  If unsure, say N.
> +
> +config XSM_FLASK_MAX_SID
> +	int "Max SID table size" if XSM_FLASK_SIDTABLE_LIMIT
> +	default 512

Hmm, wouldn't the default better be what we had so far? As per the justification
you aim at a special case (embedded) with this limit.

> +	help
> +	  The maximum amount of SIDs allocated by Xen. Default value is
> +	  approximately double the size of contexts that default Xen policy can
> +	  potentially have.

Do we need two controls? Can't 0 mean "no limit"? Or else what use is permitting
0 here as a value?

Jan

25.08.25 15:00, Jan Beulich:
> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
> 
> I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
> file there.

you mean something like Kconfig.xsm in the same common/ directory? Or 
move this Kconfig out into xsm/ directory with the rest of flask code?

> 
>> @@ -418,6 +418,25 @@ config XSM_FLASK_AVC_STATS
>>   
>>   	  If unsure, say Y.
>>   
>> +config XSM_FLASK_SIDTABLE_LIMIT
>> +	def_bool n
> 
> This makes little sense; just "bool" would have the same effect. Yet then
> you can combine that with ...
> 
>> +	prompt "Limit the size of SID table" if EXPERT
> 
> ... this line.
> 
>> +	depends on XSM_FLASK
>> +	---help---
> 
> No triple dashes around "help" anymore, please.
> 
>> +	  Limit the number of security identifiers allocated and operated by Xen.
>> +	  This will limit the number of security contexts and heap memory
>> +	  allocated for SID table entries.
>> +
>> +	  If unsure, say N.
>> +
>> +config XSM_FLASK_MAX_SID
>> +	int "Max SID table size" if XSM_FLASK_SIDTABLE_LIMIT
>> +	default 512
> 
> Hmm, wouldn't the default better be what we had so far? As per the justification
> you aim at a special case (embedded) with this limit.
> 

yes, we can have a default value of UINT_MAX specified here if we'll use 
base-2 exponent as a value. And get rid of second option.


   -Sergiy

On 29.08.2025 13:33, Sergiy Kibrik wrote:
> 25.08.25 15:00, Jan Beulich:
>> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>
>> I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
>> file there.
> 
> you mean something like Kconfig.xsm in the same common/ directory? Or 
> move this Kconfig out into xsm/ directory with the rest of flask code?

The latter would be preferable imo.

Jan

29.08.25 14:44, Jan Beulich:
> On 29.08.2025 13:33, Sergiy Kibrik wrote:
>> 25.08.25 15:00, Jan Beulich:
>>> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>
>>> I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
>>> file there.
>>
>> you mean something like Kconfig.xsm in the same common/ directory? Or
>> move this Kconfig out into xsm/ directory with the rest of flask code?
> 
> The latter would be preferable imo.

then it probably will have to be moved outside Common Features menu and 
into the main configuration menu, while having 6-7 items. Is it ok to 
keep such small submenu for that?

  -Sergiy

On 30.08.2025 17:23, Sergiy Kibrik wrote:
> 29.08.25 14:44, Jan Beulich:
>> On 29.08.2025 13:33, Sergiy Kibrik wrote:
>>> 25.08.25 15:00, Jan Beulich:
>>>> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>>>>> --- a/xen/common/Kconfig
>>>>> +++ b/xen/common/Kconfig
>>>>
>>>> I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
>>>> file there.
>>>
>>> you mean something like Kconfig.xsm in the same common/ directory? Or
>>> move this Kconfig out into xsm/ directory with the rest of flask code?
>>
>> The latter would be preferable imo.
> 
> then it probably will have to be moved outside Common Features menu and 
> into the main configuration menu, while having 6-7 items. Is it ok to 
> keep such small submenu for that?

I think so.

Jan