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

Re: [PATCH for-4.22] XSM: guard .sysctl() and .readconsole() hooks


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Thu, 18 Jun 2026 08:40:50 -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=1781786454; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=C2ygIbhffl1iDYoikiKD6fli2ANxoIlWi8qio3DbWSs=; b=hqPc774sRahAnVbM5zA119yjXSxK2zE8EeR79AmZ5KpgFVdCldmFQnNdStFlaJZqAt1+Ak7sB6j45J3UIdTFrFG0vi82jI0dkTOVd5eNLD/1U5BFGVc/rHKBWd5dEzpZ6gxO9IGv/8PItpdOfTz+GntoLMl0uCPEKwpUqaNn+AY=
  • Arc-seal: i=1; a=rsa-sha256; t=1781786454; cv=none; d=zohomail.com; s=zohoarc; b=CsaCKdfsSZYdlS/2H+1B1H0y+rircLnW/iWnwfGdbW/MxyeVt4uq0GkXSLy6E18CXl5XlRO170ZC5uoFKTveiVwbGy6SP6mQVVkSelgB78AkVnzyo8sD4WY46+HEHw4fYjzPxNC6XtT2cYjaEskEUEQXl84B9j7EVVRU5xwIA5c=
  • 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:Cc:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
  • Cc: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 18 Jun 2026 12:41:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 6/18/26 8:23 AM, Jan Beulich wrote:
On 18.06.2026 14:13, Andrew Cooper wrote:
On 18/06/2026 12:32 pm, Jan Beulich wrote:
Leaving the hook pointers in struct xsm_ops when !SYSCTL would lead to
the BUG_ON() in xsm_fixup_ops() triggering for respectively configured
hypervisors.

While moving the #ifdef for the corresponding xsm_*() wrappers, also move
those for xsm_page_offline() (where the hook pointer field already is
suitably guarded).

Fixes: c9eabaa03a68 ("xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL")
Fixes: bddd9af6049f ("xen/sysctl: wrap around XEN_SYSCTL_readconsole")
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Ugly.  We probably ought to see about booting the RANDCONFIG hypervisor
too, which should be able to spot things like this.

This is a regression vs 4.21, so does need including.

Aiui it's a regression vs 4.20, i.e. will want backporting to 4.21.

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, although...

Thanks.

--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -61,8 +61,10 @@ struct xsm_ops {
  #endif
      int (*set_target)(struct domain *d, struct domain *e);
      int (*domctl)(struct domain *d, struct xen_domctl *op);
+#ifdef CONFIG_SYSCTL
      int (*sysctl)(int cmd);
      int (*readconsole)(uint32_t clear);
+#endif

... this is now the 3rd CONFIG_SYSCTL in xsm_ops.

I know it will grow the diff, but can we see about collecting them into
a single region, and in dummy_ops too?  It will shrink the overall
result, and the order of pointers in this ops structure is uninteresting.

I have a far more consolidating patch in the works, which is how I actually
noticed the issue. I'd prefer to keep things as simple as possible here.

Would also be good to clean up flask_ops similarly.

v/r,
dps




 


Rackspace

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