From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: "Juergen Gross" <jgross@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>
Subject: [PATCH v2 0/4] tools/xenstore: fix issue related to XSA-417
Date: Wed, 29 Apr 2026 14:06:15 +0200 [thread overview]
Message-ID: <20260429120619.1013440-1-jgross@suse.com> (raw)
There is one corner case of XSA-417 which wasn't handled completely
with the patches back then.
The XSA-417 fixes tried to solve the problem, that a new domU would
inherit access permissions to access Xenstore entries with that domid
listed in the access rights. In order not to make it easy for a domU
to query existence of a domid, adding permission for a non-existing
domain is not rejected by Xenstore. The XSA-417 patches solved that
problem by adding a flag to a permission entry referencing a not
existing domain, indicating that the permission should not be
effective for Xenstore.
One corner case was not handled:
Consider guest 1 and guest 2 running. Guest 1 adds guest 2 to be able
to access a Xenstore entry. Now guest 2 is removed from the system and
a new guest 3 with the same domid as guest 2 had is being created.
When guest 3 would try now to access the Xenstore entry, it would fail,
as Xenstore would see that the Xenstore entry is older than guest 3.
But if guest 1 is modifying the permissions of the Xenstore entry
again, e.g. by adding another domain, the permission entry for guest 2
would lose its "special flag", resulting in guest 3 now really gaining
access to the Xenstore entry.
This series is fixing this problem by the following means:
- In order to allow guests to know that a Xenstore entry permission
might have gone stale, allow unprivileged guests to receive
@releaseDomain watch events. This doesn't open a security hole, as
the only knowledge which can by gathered from that change is that a
domain is gone, not that a domain with a specific domid is existing.
- When a domain is removed, remove all permissions relating to this
domain from all Xenstore entries.
Note that this issue was discussed by the Xen security team and we
decided not to issue an XSA, as there are no known use cases where one
unprivileged guest would grant access to its Xenstore nodes to more
than one other unprivileged guests.
We decided to delay this patch series until the watch depth feature has
been committed, as with that feature available it is now possible for
a guest to handle the death of a specific domain in a sane way.
Changes in V2:
- some minor comments addressed
Denis Mukhin (1):
xen/public: introduce DOMID_ANY
Juergen Gross (3):
tools/xenstored: add support for "all domains" node permission
tools/xenstored: allow @releaseDomain watch for all domains
tools/xenstored: remove permissions related to dead domain
docs/man/xl.cfg.5.pod.in | 4 ++
tools/xenstored/core.c | 45 ++++++++++++++-----
tools/xenstored/domain.c | 78 +++++++++++++++++++++------------
tools/xenstored/domain.h | 3 +-
xen/include/public/io/xs_wire.h | 2 +
xen/include/public/xen.h | 7 +++
6 files changed, 100 insertions(+), 39 deletions(-)
--
2.53.0
next reply other threads:[~2026-04-29 12:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 12:06 Juergen Gross [this message]
2026-04-29 12:06 ` [PATCH v2 1/4] xen/public: introduce DOMID_ANY Juergen Gross
2026-05-14 1:15 ` Stefano Stabellini
2026-04-29 12:06 ` [PATCH v2 2/4] tools/xenstored: add support for "all domains" node permission Juergen Gross
2026-04-29 12:06 ` [PATCH v2 3/4] tools/xenstored: allow @releaseDomain watch for all domains Juergen Gross
2026-04-29 12:06 ` [PATCH v2 4/4] tools/xenstored: remove permissions related to dead domain Juergen Gross
2026-04-29 16:41 ` Jason Andryuk
2026-05-07 7:43 ` Jürgen Groß
2026-05-07 7:53 ` Jan Beulich
2026-05-12 15:48 ` [PATCH v2 0/4] tools/xenstore: fix issue related to XSA-417 Oleksii Kurochko
2026-05-12 15:52 ` Jürgen Groß
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260429120619.1013440-1-jgross@suse.com \
--to=jgross@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.