From nobody Fri Oct 31 04:06:25 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=quarantine dis=quarantine) header.from=epam.com Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1751273808295873.9658404661859; Mon, 30 Jun 2025 01:56:48 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1028954.1402667 (Exim 4.92) (envelope-from ) id 1uWAJF-0003S1-U4; Mon, 30 Jun 2025 08:56:17 +0000 Received: by outflank-mailman (output) from mailman id 1028954.1402667; Mon, 30 Jun 2025 08:56:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uWAJF-0003Ru-RN; Mon, 30 Jun 2025 08:56:17 +0000 Received: by outflank-mailman (input) for mailman id 1028954; Mon, 30 Jun 2025 08:56:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uWAJE-0003Ro-OP for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:56:16 +0000 Received: from fforwardh-b1-smtp.messagingengine.com (fforwardh-b1-smtp.messagingengine.com [202.12.124.196]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0e79bdf3-5590-11f0-b894-0df219b8e170; Mon, 30 Jun 2025 10:56:06 +0200 (CEST) Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfforwardh.stl.internal (Postfix) with ESMTP id 9B4DB8400E0; Mon, 30 Jun 2025 04:56:04 -0400 (EDT) Received: from phl-frontend-02 ([10.202.2.161]) by phl-compute-09.internal (MEProxy); Mon, 30 Jun 2025 04:56:04 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 Jun 2025 04:56:02 -0400 (EDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0e79bdf3-5590-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1751273764; x=1751360164; bh=/DHgYG9ZyvfdKqKdCRbmzkrxhWwhBHN6qVw 9SBZbsVg=; b=TeZgO9LIPmI6rG1ncsRZW7JBBArhk2kNRe0bQRI0f7L0AfaDtyX rebk1QNT4acQUtMfUX5L7haJgAPM9z9g2SvCbQ67YM7sFrqFgwkhdbj02ly2scNk JGRqS8sLctDEOAekLlGUS5SzaV37mHS4TEb8dlf63jGQmtm7EboyK7jErHgppW/t N/vuflLXDwmOPRDloyHGCcL4umY1cQeitTZZqyfdDwCFIDsqX2tuqHXmre2+86SW 4sjotwXxbOueMSXp62bXgAjJhZhrfPqJ7+j6++lasLOcu09PnTMSoozJA/Pb11oL i4nKafnsTFbJVgUbVvxznCpw3nD3wPODKSg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduuddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffoggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhihicumfhi sghrihhkuceoufgvrhhgihihpgfmihgsrhhikhesvghprghmrdgtohhmqeenucggtffrrg htthgvrhhnpeffffdvieefieejhfehfeeuvdevtdehffejieevhefgteetvdegudejgfdu jeegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghkihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopedutddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi gvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgvrhhgihihpghkihgsrhhikhes vghprghmrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrh higidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdr thgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtg hpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgv nhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg homhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: if663d99b:Fastmail From: Sergiy Kibrik To: xen-devel@lists.xenproject.org Cc: Sergiy Kibrik , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" Subject: [RFC PATCH] xen/flask: estimate max sidtable size Date: Mon, 30 Jun 2025 11:55:59 +0300 Message-Id: <20250630085559.554334-1-Sergiy_Kibrik@epam.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1751273810467116600 Content-Type: text/plain; charset="utf-8" Currently Xen lacks a defined largest number of security IDs it can potenti= ally 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. Thus in Xen the number of allocated entries in sidtable is hard-limited by = UINT_MAX. However in the embedded environment configured for safety it is desirable to avoid guest-triggered dynamic memory allocations at runtime, or at least li= mit them to some decent amounts. So we seek to estimate this limit. This patch suggests one way to do it using Xen's flask policy. List of users, roles and types is read from binary policy using setools uti= ls, then it is used to count the No. of combinations these values can give. This No. of combinations then can be used in code as a practical replacement of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at bo= ot and avoid runtime entries allocation altogether. Signed-off-by: Sergiy Kibrik --- This RFC presents a concept of estimating a max possible sidtable size. Can we discuss how valid this concept is? Currently it yields 420 as max SI= D, is it a reasonable number? Or perhaps something not being taken into accoun= t? (it lacks MLS/MCS support, because it's currently disabled in Xen's policy and I'm not sure if it's usable) -Sergiy --- .gitignore | 1 + xen/xsm/flask/Makefile | 5 ++++- xen/xsm/flask/policy/mkselim.sh | 17 +++++++++++++++++ xen/xsm/flask/ss/sidtab.c | 3 ++- 4 files changed, 24 insertions(+), 2 deletions(-) create mode 100755 xen/xsm/flask/policy/mkselim.sh diff --git a/.gitignore b/.gitignore index 53f5df0003..b03e63b7a0 100644 --- a/.gitignore +++ b/.gitignore @@ -241,6 +241,7 @@ xen/xsm/flask/include/av_permissions.h xen/xsm/flask/include/class_to_string.h xen/xsm/flask/include/flask.h xen/xsm/flask/include/initial_sid_to_string.h +xen/xsm/flask/include/se_limits.h xen/xsm/flask/policy.* xen/xsm/flask/xenpolicy-* tools/flask/policy/policy.conf diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile index 3fdcf7727e..8acc5efcf1 100644 --- a/xen/xsm/flask/Makefile +++ b/xen/xsm/flask/Makefile @@ -14,7 +14,7 @@ AV_H_DEPEND :=3D $(srcdir)/policy/access_vectors =20 FLASK_H_FILES :=3D flask.h class_to_string.h initial_sid_to_string.h AV_H_FILES :=3D av_perm_to_string.h av_permissions.h -ALL_H_FILES :=3D $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES)) +ALL_H_FILES :=3D $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES) se_li= mits.h) =20 # Adding prerequisite to descending into ss/ folder only when not running # `make *clean`. @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE FLASK_BUILD_DIR=3D$(FLASK_BUILD_DIR) POLICY_FILENAME=3D$(POLICY_S= RC) cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ =20 +$(obj)/%/se_limits.h: $(obj)/policy.bin + $(srcdir)/policy/mkselim.sh $^ $@ + clean-files :=3D policy.* $(POLICY_SRC) diff --git a/xen/xsm/flask/policy/mkselim.sh b/xen/xsm/flask/policy/mkselim= .sh new file mode 100755 index 0000000000..bda99727fa --- /dev/null +++ b/xen/xsm/flask/policy/mkselim.sh @@ -0,0 +1,17 @@ +#!/bin/sh + +policy=3D$1 +output_file=3D$2 +ntypes=3D$(seinfo --flat $policy -t | wc -l) +nroles=3D$(seinfo --flat $policy -r | wc -l) +nusers=3D$(seinfo --flat $policy -u | wc -l) +cat > $output_file << EOF +/* This file is automatically generated. Do not edit. */ +#ifndef _SELINUX_LIMITS_H__ +#define _SELINUX_LIMITS_H__ +#define __SEPOL_USERS_MAX $nusers +#define __SEPOL_ROLES_MAX $nroles +#define __SEPOL_TYPES_MAX $ntypes +#define SEPOL_SID_LIMIT ( __SEPOL_USERS_MAX * __SEPOL_ROLES_MAX * __SEPOL_= TYPES_MAX ) +#endif +EOF diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c index 69fc3389b3..0dbadc8cd7 100644 --- 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" =20 #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) =20 @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct cont= ext *context, if ( sid ) goto unlock_out; /* No SID exists for the context. Allocate a new one. */ - if ( s->next_sid =3D=3D UINT_MAX || s->shutdown ) + if ( s->next_sid =3D=3D SEPOL_SID_LIMIT || s->shutdown ) { ret =3D -ENOMEM; goto unlock_out; --=20 2.25.1