lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250513163144.2215824-1-maz@kernel.org>
Date: Tue, 13 May 2025 17:31:39 +0100
From: Marc Zyngier <maz@...nel.org>
To: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Sascha Bischoff <sascha.bischoff@....com>,
	Timothy Hayes <timothy.hayes@....com>
Subject: [PATCH v2 0/5] genirq/msi: Fix device MSI prepare/alloc sequencing

While reviewing (and debugging) the GICv5 code, it became obvious that there
was something pretty fishy about the way MSI allocation was taking place in
respect to the msi_prepare() callback.

There is a strong (though not 100% explicit) requirement that the
.msi_prepare() callback must take place exactly once during the lifetime of
an MSI domain, before any MSI is allocated. Sadly, that's not how the core
code behaves, leading to all sorts of "interesting" issues with MBIGEN or
the GICv5 IWB.

The fix is both simple and surprisingly convoluted. The first course of
action would be to hoist the "prepare" action before we allocate any MSI,
adding new tracking for the msi_alloc_info_t structure.

But this unveils another issue that the core code has been papering over,
which is that there is no pendant to the .msi_prepare() callback that would
be called on irqdomain destruction, and that at least the ITS code has been
using some crap heuristics to work around it.

So this needs to be addressed first, and that's the point of the first two
patches, introducing and implementing the .msi_teardown() callback.  The
.msi_prepare() call is then moved is the specific case of device-MSI, and
the .msi_teardown() callback wired up.

The last patch remove a gross hack in the ITS msi-parent code, which
was papering over the broken use of the "prepare" callback.

This has been tested on a GICv4 system with MBIGEN, patches on top of
tip/irq/msi (a1d8a83093675).

* From v1 [1]:

  - Fixed blunder in the ITS .msi_teardown()

  - Fixed spelling, grammar, and other use of unclear terms

  - Fixed line splitting, disgraceful underscores

  - Split the calling of .msi_teardown() into its own patch

  - Rebased on top of tip/irq/msi

[1] https://lore.kernel.org/r/20250511163520.1307654-1-maz@kernel.org

Marc Zyngier (5):
  genirq/msi: Add .msi_teardown() callback as the reverse of
    .msi_prepare()
  irqchip/gic-v3-its: Implement .msi_teardown() callback
  genirq/msi: Move prepare() call to per-device allocation
  genirq/msi: Engage the .msi_teardown() callback on domain removal
  irqchip/gic-v3-its: Use allocation size from the prepare call

 drivers/irqchip/irq-gic-v3-its-msi-parent.c | 29 +++++--------
 drivers/irqchip/irq-gic-v3-its.c            | 46 +++++++++++----------
 include/linux/msi.h                         | 12 +++++-
 kernel/irq/msi.c                            | 45 ++++++++++++++++++--
 4 files changed, 86 insertions(+), 46 deletions(-)

-- 
2.39.2


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ