From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88CEFFF8867 for ; Wed, 29 Apr 2026 12:07:13 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1297273.1573349 (Exim 4.92) (envelope-from ) id 1wI3gX-0006Rk-Gm; Wed, 29 Apr 2026 12:06:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1297273.1573349; Wed, 29 Apr 2026 12:06:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wI3gX-0006Rd-Ci; Wed, 29 Apr 2026 12:06:33 +0000 Received: by outflank-mailman (input) for mailman id 1297273; Wed, 29 Apr 2026 12:06:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wI3gV-0006RX-DV for xen-devel@lists.xenproject.org; Wed, 29 Apr 2026 12:06:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wI3gU-00FgZi-Py for xen-devel@lists.xenproject.org; Wed, 29 Apr 2026 14:06:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 69f1f444-5cb7-0a2a0a5109dd-0a2a4503d97c-12 for ; Wed, 29 Apr 2026 14:06:30 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.56.1) (envelope-from ) id 69f1f446-672d-0a2a45030019-c387df838856-3 for ; Wed, 29 Apr 2026 14:06:30 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id CF08C5BD5F; Wed, 29 Apr 2026 12:06:21 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 94F26593B0; Wed, 29 Apr 2026 12:06:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 1sI2Iz308Wk6VQAAD6G6ig (envelope-from ); Wed, 29 Apr 2026 12:06:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1777464386; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=wbjluDVZotZt60L9F+RyvmJUG+lseQlcgdHyfdTEa3g=; b=VeGvPzIkKRE75NI8Ur7ooVJ618bEDtu+MaEvc7uEL/8HaDzpNXVKFAh3NnI9a4vgn2ctUX k730HN0WxLwrWUlsHwcShi3J++vB9aNyUk6XzPyn5NQr1Af9hQwqZcNVAqOoovrgx88ZUH RvhHXxFJFOX116yDBLEQ5NndFsS5gYs= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1777464381; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=wbjluDVZotZt60L9F+RyvmJUG+lseQlcgdHyfdTEa3g=; b=BLEcjP1eFCX1oX1o9NAHfJsOF4pLKWp+J148YMsmJ95qQv3fJ84J7Y6Vv/oIUnGRjukUQ0 z+q5a3WMRUEbw5IbxYaPhkR0V+F+FpqVdmRSd1JX9z1GEYTgIIP1v9B9VcZoSFIXVA8FF3 sRQ+zQLe7X8seeVWSuViYE85JnGdoxk= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 0/4] tools/xenstore: fix issue related to XSA-417 Date: Wed, 29 Apr 2026 14:06:15 +0200 Message-ID: <20260429120619.1013440-1-jgross@suse.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-purgate-ID: tlsNG-33051d/1777464390-A197D938-9D91CD56/0/0 X-purgate-type: clean X-purgate-size: 2909 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