On Sun, Jun 07, 2026 at 08:37:45PM +0000, Pranjal Shrivastava wrote: > On Fri, May 22, 2026 at 08:24:06PM +0000, David Matlack wrote: > > Inherit Access Control Services (ACS) flags on all incoming preserved > > devices (endpoints and upstream bridges) during a Live Update. > > > > Inheriting ACS flags avoids changing routing rules while memory > > transactions are in flight from preserved devices. This is also strictly > > necessary to ensure that IOMMU group assignments do not change across > > a Live Update for preserved devices, as changing ACS configurations can > > split or merge IOMMU groups. > > > > Cache the inherited ACS controls established by the previous kernel in > > struct pci_dev so that ACS controls do not change after a reset > > (pci_restore_state() calls pci_enable_acs()). > > > > To simplify ACS inheritance, reject preserving any devices that require > > quirks to enable ACS as those quirks would also have to take Live Update > > into account. > > > > Signed-off-by: David Matlack <[email protected]> > > --- > > drivers/pci/liveupdate.c | 68 ++++++++++++++++++++++++++++++++++ > > drivers/pci/liveupdate.h | 11 ++++++ > > drivers/pci/pci.c | 5 +++ > > drivers/pci/pci.h | 5 +++ > > drivers/pci/quirks.c | 7 ++++ > > include/linux/pci_liveupdate.h | 6 +++ > > 6 files changed, 102 insertions(+) > > > > [...] > > > > > +void pci_liveupdate_init_acs(struct pci_dev *dev) > > +{ > > + guard(rwsem_read)(&pci_liveupdate.rwsem); > > + > > + if (!dev->acs_cap || !dev->liveupdate.incoming) > > + return; > > + > > + pci_read_config_word(dev, dev->acs_cap + PCI_ACS_CTRL, > > &dev->liveupdate.acs_ctrl); > > I might be thinking out loud here, but as an attacker, this motivates me > to somehow hack the EP FW to mis-report the PCI_ACS_CTRL register across > a liveupdate to fool the incoming kernel. If the FW feeds a 0, it silently > strips ACS protections.
Minor note here: I used "0" as an example value, I'm aware that'll effectively disable ACS and kernel will enforce more security. My point was that a FW exploit can meddle with the bitfields of the ACS_CTRL to spoof and mis-report the ACS flags. Additionally, we might give rise to use-cases that start depending on this, for e.g. if someone wants to change ACS policies in the new kernel, the FW may silently update these flags across a kexec. > > Should we also serialize ACS state in ser somehow to ensure we aren't > fooled by something like this? > Thanks, Praan
