Re: [RFC PATCH] xen/flask: estimate max sidtable size

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 4 Jul 2025, Jan Beulich wrote:
> On 04.07.2025 12:10, Sergiy Kibrik wrote:
> > 01.07.25 13:42, Jan Beulich:
> >> On 30.06.2025 10:55, Sergiy Kibrik wrote:
> >>> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE
> >>>                   FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) 
> >>> POLICY_FILENAME=$(POLICY_SRC)
> >>>           cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@
> >>>   
> >>> +$(obj)/%/se_limits.h: $(obj)/policy.bin
> >>> + $(srcdir)/policy/mkselim.sh $^ $@
> >>
> >> Hmm, that's using the built-in policy, isn't it? What if later another
> >> policy is loaded? Wouldn't it be possible to have ...
> >>
> >>> --- a/xen/xsm/flask/ss/sidtab.c
> >>> +++ b/xen/xsm/flask/ss/sidtab.c
> >>> @@ -13,6 +13,7 @@
> >>>   #include "flask.h"
> >>>   #include "security.h"
> >>>   #include "sidtab.h"
> >>> +#include "se_limits.h"
> >>>   
> >>>   #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK)
> >>>   
> >>> @@ -228,7 +229,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 == SEPOL_SID_LIMIT || s->shutdown )
> >>
> >> ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even 
> >> set?
> >>
> > 
> > It's using a policy from tools/flask/policy, yes. But not a built-in 
> > policy, just reusing a bit of code from that code. The idea is that we 
> > can have CONFIG_XSM_FLASK_POLICY option disabled yet still be able to 
> > calculate SEPOL_SID_LIMIT.
> > 
> > As for loading another policy at runtime -- the calculated 
> > SEPOL_SID_LIMIT=384 for current master flask policy is still pretty big 
> > limit. From what I can see -- much less No. contexts are being used on a 
> > running system, because most of calculated combinations of 
> > user/role/type are not really usable (e.g. contexts with xen_t or 
> > xenboot_t types and user_1 user are not expected etc). So there should 
> > be enough room even for more complex custom policies.
> 
> But still there could be odd ones. Imo such a static limit can then only be
> introduced via Kconfig option.

I was going to suggest the same approach as Jan. While I appreciate
Sergiy's effort to calculate the limit automatically using mkselim.sh,
I think that for our purposes, a simple Kconfig option specifying the
maximum allocation limit is sufficient.

This type of limit is typically chosen before moving into production,
after extensive experimentation, measurements, and certifications.
Therefore, it is not necessary to make it easier for users to configure
it optimally based on policy.  However, we do need a way to enforce a
limit, and a straightforward Kconfig option would be adequate for that.