[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure


  • To: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 3 Oct 2026 16:32:15 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1791059536; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=QxLauvXIkEfQdv0YGMb5jRArVzzhaW9TyHftDpWOvbg=; b=hr3FFakmlYSvynPbXRS/lIIpPEXUXUyDp9otSrtWlzzFGZubN3sUi4iMlE7RrVeh0BqAk4KFy7fhjh6hhCL/QDKGwlh4otxpDZQ5YkNfYH/zWcpiSnYPF473aQngdr6oJ5ys3ay83qJc9fFWb8FWpha4eXWdJ9J34CXlADjIa0U=
  • Arc-seal: i=1; a=rsa-sha256; t=1791059536; cv=none; d=zohomail.com; s=zohoarc; b=WsPDt3BSh7Cbx0ZKgUSSaKFRs4dR01oEWCoBPyp1fgOkZsAcpQBXt7OVeaNU3v30hoF6/jW1J7ziydf8OABRFEG7auBVL0ufBoDZgtQ0SEOAAnruHp3n8w5WzLfgb/KR7rpb1WmsYi/RLLhRjw9uQUrmfmSUR/8H4MOEkstQlP8=
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@xxxxxxxxxxxxxxxxxxxx" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
  • Delivery-date: Sat, 03 Oct 2026 20:32:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hey Sergiy,

Apologies for not getting a response on the first send, been a bit preoccupied with preparing customer delivery.

On 10/2/26 5:26 AM, Sergiy Kibrik wrote:
Error path of failed sidtab_map() leaves global sidtab in shutdown state and
from that point system is unable to allocate new SIDs in 
sidtab_context_to_sid().
To restore sidtab state new function sidtab_activate() is introduced, which only
resets shutdown flag, rewinding effect of sidtab_shutdown().

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>
---
New function is not strictly required, this also can be achieved just by
doing sidtab_set(&sidtab, &sidtab), but this way we would rely on its
undocumented internal behaviour.
---
  xen/xsm/flask/ss/services.c | 1 +
  xen/xsm/flask/ss/sidtab.c   | 7 +++++++
  xen/xsm/flask/ss/sidtab.h   | 1 +
  3 files changed, 9 insertions(+)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 35ad1034ca..f5cee1e0b0 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1427,6 +1427,7 @@ int security_load_policy(const void *data, size_t len)
      if ( sidtab_map(&sidtab, clone_sid, &newsidtab) )
      {
          rc = -ENOMEM;
+        sidtab_activate(&sidtab);
          goto err;
      }
diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c
index 69fc3389b3..5d1653cd02 100644
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -314,6 +314,13 @@ void sidtab_set(struct sidtab *dst, struct sidtab *src)
      SIDTAB_UNLOCK(src);
  }
+void sidtab_activate(struct sidtab *s)
+{
+    SIDTAB_LOCK(s);
+    s->shutdown = 0;
+    SIDTAB_UNLOCK(s);
+}
+

I think calling this sidtab_activate is a bit misleading, as activation is really the success path of security_load_policy. Perhaps sidtab_cancel_shutdown?


If you're not opposed to the rename, then on respin,

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.