On Thu, Jun 19, 2025 at 11:06 PM Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote: > > On Thu, Jun 19, 2025 at 12:56:12PM -0700, Stefano Stabellini wrote: > > On Thu, 19 Jun 2025, Marek Marczykowski-Górecki wrote: > > > On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote: > > > > I think a section on PCI passthrough is also warranted. i.e. preventing > > > > misuse > > > > of a device to exploit Secure Boot. > > > > > > While I agree it makes sense, I wonder if it's in scope for UEFI > > > Secure Boot as defined by Microsoft? It may have implication for example > > > on PCI passthrough to a PV domains. > > > > If we bring DomUs into the discussion, then I think we need to make a > > distinction between predefined DomUs, which could have signatures > > verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests), > > and other dynamically created DomUs which could be fetched from the > > network and potentially started without signature verification or prior > > knowledge. > > I think it's mostly not about what's running inside domU, but what such > domU has access to. The obvious part is enforcing IOMMU configuration so > that domU cannot use a PCI device as a proxy to modify hypervisor (or > dom0) code. But there may be more subtleties like access to specific > devices (HECI? SPI?). > Anyway, lets figure out first _if_ we need to do something about this > topic, and only then worry how. >
As far as I know, Microsoft haven't specified requirements to this level of detail. However, if userspace can break the Secure Boot principles laid out above using a (spec compliant) PCI device to write memory, then I don't see why it would be any different to a Secure Boot compromise using the CPU to write memory. Linux prevents direct access to PCI devices when lockdown mode is enabled, presumably to prevent these kinds of attacks. Ross
