From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7AFAB366566 for ; Tue, 9 Jun 2026 17:20:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781025626; cv=none; b=Be9AgFXX2L5gbweJMhOIG9+6OqzM1qGrqCPLz/4VuGb6Wdo4wC1kMIJUvmaxeNx0GmtDSUA5kJOwFZDvJwGrj3FV9wbke+P8Hi6oEj+uwU4qzleG7Nw433rRWIbIDv0fFK+w2awhXG/hwQZzYsab3WxwKB4VrHRTft3Dq472omY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781025626; c=relaxed/simple; bh=TK2+t/up9BNHR7cWnWPkUKbCONbG+0KU9N82d806Hmo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MynMHtFeJwqYqZxff19nEO3k0QUctXStEqBqHQWybh9p05mzHgE3m6g/7+MWEE5XHJK/aqA2CJmhrQFjiIkqTIXlL6pMd3zq8lBB7ZhBpDr+3eyzWkkgy5urYt0ktkwbHYG1Zb7/XTJzsw5oXUCNgHIkbwvRwHrOKmHIt+zRVNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=LAtm0tOB; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="LAtm0tOB" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2bf22c18ad3so553715ad.0 for ; Tue, 09 Jun 2026 10:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781025625; x=1781630425; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=01u/8EAi6NGn4gFgEAFXoW9+VQRDowjxcP1j39dvRbk=; b=LAtm0tOBO31AXYeLi+UB/W5ChfPBv3oU+N91irOeaQv2UaSvc4ibQqfOhFM2llBMnq 9c+zb+lQb1MJoHIvMgh5a2fef7nDaqbOF/tV7o412PzQUtKoHlqpD81ryv0GWb6TtyNU KxiGVOXcdiwTR1UK/SoPG9h9psrI4i3uoRBXBL3hTf1kSwY21797gp4coe3iLLzL9JB6 QXRhFmgnggvxP05kngC+5yWNlQuPldM81OBlBnScOp3j8gm9eVcmeiLnEM8SruNTfe9h e82pHa1gA7J6PxbVTQr9HwTAPTe7v1x0eLnFc+SDiR7R/GoPIBE9+qO0CLvRTWg5ZYpy LIlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781025625; x=1781630425; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=01u/8EAi6NGn4gFgEAFXoW9+VQRDowjxcP1j39dvRbk=; b=IicbJaiFXjrJj1B/JkXKBT7eK8E7die3QoTrecuB4x1+ljsqf2o6wvKm7GZcCZAQCf zS+aimDB6XWMmvYyZ5vLVW2vSI0RFFj882AfVNNiDwv7CgTOwTPR7jzt9rYT93YNfDCX 0XLodshFGQwPo/8AXTU8Qgw9yUMxPwQYLl6Y6CYzqCd1oaFOL458wqp95bxGrj1v5CZ8 6hHjWlHQvHs8bIfMasFR/bL56Cbo/FNnf1kMWR+W9tkQmTntgeX1qEkM9rMznfNlrPF3 0naC6yNtANtfCitnykBbmqWvnzhvuDi4wCbJng/wtz8gD6flHBVGvYP6+LJaFZtrQUoj Drsw== X-Forwarded-Encrypted: i=1; AFNElJ8Tvbi3s+fBboDzsG7wn4S9fCk7z6f6D+mbfwd4jh43ApCbF1yxIE1BM8Y7DfW1ekQBaIU9gzSbr2joNxc=@vger.kernel.org X-Gm-Message-State: AOJu0YybRg/Uwe1uLjdAifug7ERI6rXF74uKeYo3WIa6eSi3laZWxvVA EByLdtDl5p7TU4Bs8pZPuW2CVhxBjwn8CMgxAKuKVQeXDutqguCeZG6Eg4I5vPVsBg== X-Gm-Gg: Acq92OECo+HZLGi9S67mvjkzF/PxVp39VMlQI3fpsuejeigOcEFL1AbfuQX8CWOVTkm +gBJ5JjiqRlnTheyxKA8heVybrWZPPuAXCAHhJhApI5f2Wr/02V9mw6ZXA5HJgWNjW7lgvg15tx nRRXzQTtTlFIfd4SCSTSO1UzlRUcLN1W+U2BS0M/Sn43HhHxb1oQaQoglnXmG6XYj1/YEraFcAc cJhw0yQAqpuFirBk15qypJcS7e3oulllqDIF41hjI+22oOhvJ84Tu1Jmq3pRCgWyn5ERfheXeZ2 b5lH9KT0x2MgU4UY8j72+jgaAf4kH/v7eqIg4bGkANHdOboThBHqPOr6LaZ8lOLdNjpIgJkXfmI 6Bw0p9Iw9blBd7dOLVVrl64PnVuq4KRyZFbJg560I4p7Yj24QtwQEhnUB4xCVZVN/oJqbniy7YP B2BL5CDU7uy4+PsIAJXL5ZBepY2/9ku2n2P2N0M3rLwv4D1GXT6wvJQOwF0EkUEZY9OhLcq9thJ SP94gbDXQ== X-Received: by 2002:a17:902:e744:b0:2bd:907:2ce5 with SMTP id d9443c01a7336-2c1eafbcbdamr9084545ad.7.1781025624007; Tue, 09 Jun 2026 10:20:24 -0700 (PDT) Received: from google.com (199.255.142.34.bc.googleusercontent.com. [34.142.255.199]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36f6bf827e6sm25059778a91.1.2026.06.09.10.20.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 10:20:23 -0700 (PDT) Date: Tue, 9 Jun 2026 17:20:14 +0000 From: Pranjal Shrivastava To: David Matlack Cc: kexec@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Adithya Jayachandran , Alexander Graf , Alex Williamson , Bjorn Helgaas , Chris Li , David Rientjes , Jacob Pan , Jason Gunthorpe , Jonathan Corbet , Josh Hilke , Leon Romanovsky , Lukas Wunner , Mike Rapoport , Parav Pandit , Pasha Tatashin , Pratyush Yadav , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Vipin Sharma , William Tu , Yi Liu Subject: Re: [PATCH v6 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices Message-ID: References: <20260522202410.3104264-1-dmatlack@google.com> <20260522202410.3104264-9-dmatlack@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jun 08, 2026 at 09:56:41PM +0000, David Matlack wrote: > On 2026-06-07 08:37 PM, 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 > > > --- > > > 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. > > > > Should we also serialize ACS state in ser somehow to ensure we aren't > > fooled by something like this? > > What does "EP FW" mean? I was referring to the Endpoint Firmware (basically any SW running on a downstream device) > > Does such an attacker even need Live Update to attack the system? It > seems like such an attacker could route TLPs in whatever malicious way > they want regardless of Live Update. > I agree that compromised PCIe devices are a menace anyway. But I was talking about the potential window opened up by Live Update here, suppose we have Device A & B assigned to 2 different VMs (implying they are in separate IOMMU groups because the switch set ACS_RR = 1). Now, the attacker has an opportunity with Liveupdate, since the devices are already assigned, if *somehow* it flips a bit like ACS_RR, the incoming kernel might see both the devices in the same IOMMU group. Who detects this case and what happens if this happens if the devices are kept assigned to these VMs? Thanks, Praan