From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (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 89E6A31E858 for ; Tue, 30 Jun 2026 22:21:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.53 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782858112; cv=pass; b=gg/2zScw9/QB/xTqWVrHCvk0iTCYulHXMSJhrV7FZNj7I+db8ftkAj8pw7YHckw/f4Qog3ruzT8TzTDV7ANKlEslE/l4q6f0bHnq3HO2A3yzvVX98Yce8HtzAK5kX/HOZGdDIFvGu2DvJAF08UBQXdNbTRwnEDzvqu6NgJSbjx0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782858112; c=relaxed/simple; bh=DR0tH2IO3fN80hPp68tJnACbZx0ZviQ8SFdx1MtberI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V70R7dBUOpUwcST7PsBKSsT3oJfJWhp6WDRPN2zrbE0+LlV+bqfHjN6GZwvpA+rKVox4GXW9oW8472RDbvDwKqoEMk2fWXtGznxFavYTz5SdMV+VOu2NwyNlyrXS52tZ9kNavi3lr33aX28FTBFwA4KaWGBS7jDkjqm3byuR3w8= ARC-Authentication-Results:i=2; 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=B9WuzwHb; arc=pass smtp.client-ip=74.125.82.53 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="B9WuzwHb" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-139f1dfc9faso5304257c88.0 for ; Tue, 30 Jun 2026 15:21:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782858111; cv=none; d=google.com; s=arc-20260327; b=h6JxscSQVIz6K9ZNe2pTOnKzZ6dsVq+ty/RAJeCJ0q1q+s6wLNdZwEsI7Jkxo8sn8q lyeiPgxIrh8Y828kRibT8LI/rG372uVeYkgb4sW76HiyOf5fQQIzV3yo2lybWgFmNUoX E6v5oEpTHo7UXjtM9klh+9a+v5h+d5shLrIjjDRi8piPdlMonI64vsFVnR9r3x411i2G dGmEedEBJN2gC1mrL0815j2auA7Cc+a9DqkbFsiv3RxhPcJrT8OILzs9sOMNTJmTyj9H kl5hbaabexvtnPTY/zlcrF9fFCE0lQH76/q+W1qV52RLzxvsukBr6/qNFHdl/5WZlLhB a1cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DR0tH2IO3fN80hPp68tJnACbZx0ZviQ8SFdx1MtberI=; fh=OS0LhEphrf4c/3y3D1/D8X/uQ3BV9fA2/VAkaewOPcE=; b=mpIFBAhkearSGowFs02W59rTVuDsmCavYJAtkZrjVeF/MM7vm2m8a4YlVsiqCta3OY WwBIcTs0ad6ftWsDfUscmcEkZao2Shcuhu8u8mXXvKx/8P6nFpJ20xbC3nJjVUAXdwTF hKd99dMrYxWP88Nl6A2kjWgco5OXP2Vs1h0Sp4wBuHdX6BGavtwf4g6ix1X1IbKK4ccw vwExuN2vZif+wfMl+Aq6Pe9YCqxWfXeC7PcQ3tfFPgScTb2VHV57X7OZHrHvNQgnC8o1 +eAkuipOxTPe36cxod05RsDn0EentIBcBR/BI27FB5T9My7l+GD0rWOvGVWXwHF9xT77 0vAA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782858111; x=1783462911; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=DR0tH2IO3fN80hPp68tJnACbZx0ZviQ8SFdx1MtberI=; b=B9WuzwHbaigQyM1oU0Z7GSraufv3HeZOr/QIAwzQkrrT3V5/MUv1/kl/SB9w2vG347 /L+sF5wU1VT+LS1ZmXHhVAjX5/KkN1qwDKIlNhSsPg0vz6uwEWIWeJ8dr+xm6tvIqpcO L142kxDDlLQ3g9eMCRDgEzU+FJgyXK+vEcpF9P5/SGuNqY85f3JULLbCTGpEEavIWo+o v7ovR2UdNNmPWdFjy5YbzwG3Qh1EC6hJ3+vkhqWRosXL5ST6ZbTPfoYY0C2WYMH6aw7C VU44FFbeUKUFVxsLpHba80xb1FgZwqnTruJE8YDLo7ytL1duo0jBDKOPc6wYx7ycUF0l 9rig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782858111; x=1783462911; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DR0tH2IO3fN80hPp68tJnACbZx0ZviQ8SFdx1MtberI=; b=Kc6kmP/+3w7VTMyNb8TDn5nRxK6j0LXkRSfbGsbwcrydeoBlBiinx/nUHmReWz+wzl 2Prb9qOYohI2Hzg86nTCQ48afr41ZdfOM89lNKvIBMUxMSNE8X335EniXzxis45DHEzz 68irGUC9maC0E3FbS21b+eXkLfFy+fOuYw5ePy/+GfKuM6fBkdsNgCWaipRwjm4Q5Yik 5AY+RHq1fD3vF3MqTfUgRFk2r0N+xtkdUgFxf7AsMiARnVKD3r/7ljs2q1k23wz/g4HS q+tjxoPqp9XkvP/6k/Slo2l0tUb52Awwx/0aqBMkHwhNiLhtwM9Wtco0MLWe+g3nuqNt 9ozw== X-Forwarded-Encrypted: i=1; AFNElJ/TxVwqNg0I5+sJll8VFRpTqTDd3J7G0ioE6QUXmma18dNsR2bIRFTlhlmkXtWtUD7zcasZmQkF8+o0JPs=@vger.kernel.org X-Gm-Message-State: AOJu0YwkhVzvtRxaVl+vsaDej8tHh3l420r/bn/KSrgKR+Z5xIGqaqF1 S38EcwOoKsyBbNDWnQzDAZvUKsJ8QzSQcVbnSzE5zym2O86tOCAB//IFOGEEL/fAkExGFfFbmBj mrcSdtWbQhr9PnLTWiAeUHYXDmRZlIXfSO9Le5Zup X-Gm-Gg: AfdE7cmF0ZM5uUnCBGy0b5H6n/tkxprZtDuMXaBy/FkRWVlmPtvUBKavhQoWt+slYJo +FiLq+tSu/pHYXpNUyHd2BHWLLSN47Yc3I6NoTVXc7qMcwv1hC4HuRyyS6kI9TxzcAPPKKkbnUn wYoi2HLa++xfFd1vw/It4yUSXeQWj33qgOMc+ZwQo7ogrStzPvdljz3/S+mGGuVWfr0TOpPq8sY bIEiZE0gPiKcYm2H1jYrRN8ng1rgTwTUlzySWeSFbdRxDB+Heyw8F8TlCj5ZqyIcOHz6t75 X-Received: by 2002:a05:7022:923:b0:139:ed5d:5c9f with SMTP id a92af1059eb24-13b2a1c08bamr3407677c88.40.1782858109859; Tue, 30 Jun 2026 15:21:49 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260522202410.3104264-1-dmatlack@google.com> <20260522202410.3104264-9-dmatlack@google.com> <20260608181640.GO1962447@nvidia.com> In-Reply-To: From: David Matlack Date: Tue, 30 Jun 2026 15:21:22 -0700 X-Gm-Features: AVVi8CdGaAQOsRR3GiQD5WoDqKgNzoVt-sa6rd2Hjmz3ldGohaSjMHvZ8NY85tg Message-ID: Subject: Re: [PATCH v6 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices To: Pranjal Shrivastava Cc: Jason Gunthorpe , 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 , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 9, 2026 at 8:35=E2=80=AFAM Pranjal Shrivastava wrote: > > On Tue, Jun 09, 2026 at 03:12:11PM +0000, Pranjal Shrivastava wrote: > > On Mon, Jun 08, 2026 at 03:16:40PM -0300, Jason Gunthorpe wrote: > > > On Mon, Jun 08, 2026 at 10:49:29AM +0000, Pranjal Shrivastava wrote: > > > > > > > My point was that a FW exploit can meddle with the bitfields of the > > > > ACS_CTRL to spoof and mis-report the ACS flags. > > > > > > Devices can also ignore the ACS flags. I don't think this is an area > > > where we should be worrying about devices being actively hostile. > > > > I'm wondering what happens if we preserve IOMMU groups across a kexec, > > but a switch's ACS capability is dropped or the ACS_RR bit gets cleared= ? > > The incoming kernel assumes that it's the same ACS cap from the old one > > > > Now, the incoming kernel restores the groups assuming they're still > > isolated, but the hardware no longer enforces it, silently allowing DMA= s > > & breaking isolation? > > Again, to clarify, I'm aware that we aren't preserving IOMMU groups, > the incoming kernel has to rebuild the groups. My concern is that if the > ACS_RR bit is cleared during the kexec window, the produced grouping woul= d > be different than the old kernel. What happens if two devices on the > same bridge were assigned to 2 different VMs? In this patch the kernel reads PCI_ACS_CTRL after kexec to determine the bridge's state and uses that information going forward. We don't assume that if ACS_RR was set on the previous kernel then it is still set now. So if ACS_RR were cleared during kexec somehow, the new kernel would see that and place those devices into the same group. Someitme after that (I'm a little fuzzy on the iommufd restore path during Live Update) the kernel would try and fail to restore the 2 devices into separate domains because they are in the same group and thus the 2 different VMs would fail to come up. Of course maybe ACS_RR can somehow get cleared after the kernel reads it, but at that point the issue has nothing to do with Live Update. So that's what would happen if ACS_RR ever got cleared during kexec and seems reasonable to me?