Linux-PCI Archive on
 help / color / Atom feed
From: Laszlo Ersek <>
To: Ard Biesheuvel <>,
	Matthew Garrett <>
Cc: linux-efi <>,
	the arch/x86 maintainers <>,
	linux-pci <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] [EFI,PCI] Allow disabling PCI busmastering on bridges during boot
Date: Tue, 3 Dec 2019 14:38:18 +0100
Message-ID: <> (raw)
In-Reply-To: <>

On 12/03/19 12:54, Ard Biesheuvel wrote:
> (+ Laszlo)
> On Tue, 3 Dec 2019 at 00:43, Matthew Garrett <> wrote:
>> On Mon, Dec 2, 2019 at 4:40 PM Matthew Garrett
>> <> wrote:
>>> Add an option to disable the busmaster bit in the control register on
>>> all PCI bridges before calling ExitBootServices() and passing control to
>>> the runtime kernel. System firmware may configure the IOMMU to prevent
>>> malicious PCI devices from being able to attack the OS via DMA. However,
>>> since firmware can't guarantee that the OS is IOMMU-aware, it will tear
>>> down IOMMU configuration when ExitBootServices() is called. This leaves
>>> a window between where a hostile device could still cause damage before
>>> Linux configures the IOMMU again.

(1) This vaguely reminds me of

(2) I'm not 100% convinced this threat model -- I hope I'm using the
right term -- is useful. A PCI device will likely not "itself" set up
DMA (maliciously or not) without a matching driver. The driver will
likely come from the device too (option ROM). The driver will program
the device to do DMA. So, whatever the system firwmare does wrt. the
IOMMU for OS protection purposes, the device driver from the option ROM
can undo.

Is this a scenario where we trust the device driver that comes from the
device's ROM BAR (let's say after the driver passes Secure Boot
verification and after we measure it into the TPM), but don't trust the
silicon jammed in the motherboard that presents the driver?

(3) I never understood why the default behavior (or rather, "only"
behavior) for system firmware wrt. the IOMMU at EBS was "whitelist
everything". Why not "blacklist everything"?

I understand the compat perspective, but the OS should at least be able
to request such a full blackout through OsIndications or whatever. (With
the SEV IOMMU driver in OVMF, that's what we do -- we set everything to

>> I don't know enough about ARM to know if this makes sense there as well. Anyone?
> There is no reason this shouldn't apply to ARM, but disabling bus
> mastering like that before the drivers themselves get a chance to do
> so is likely to cause trouble. Network devices or storage controllers
> that are still running and have live descriptor rings in DMA memory
> shouldn't get the rug pulled from under their feet like that by
> blindly disabling the BM attribute on all root ports before their
> drivers have had the opportunity to do this cleanly.

I agree.

> One trick we implemented in EDK2 for memory encryption was to do the
> following (Laszlo, mind correcting me here if I am remembering this
> wrong?)
> - create an event X
> - register an AtExitBootServices event that signals event X in its handler
> - in the handler of event X, iterate over all PPBs to clear the bus
> master attribute
> - for bonus points, do the same for the PCIe devices themselves,
> because root ports are known to exist that entirely ignore the BM
> attribute
> This way, event X should get handled after all the drivers' EBS event
> handlers have been called.

Yes. Please see the commit message and the code comments in the
following edk2 commit:

I'm unsure how portable it is to platforms that are not derived from edk2.


  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  0:40 Matthew Garrett
2019-12-03  0:42 ` Matthew Garrett
2019-12-03 11:54   ` Ard Biesheuvel
2019-12-03 13:38     ` Laszlo Ersek [this message]
2019-12-03 19:36       ` Matthew Garrett
2019-12-03 19:40     ` Matthew Garrett
2019-12-04  7:11       ` Laszlo Ersek
2019-12-04 19:29         ` Matthew Garrett
2019-12-03 15:30 ` Andy Lutomirski
2019-12-03 16:33   ` Ard Biesheuvel
2019-12-03 19:41   ` Matthew Garrett
2019-12-04 19:50     ` Andy Lutomirski
2019-12-04 19:56       ` Matthew Garrett
2019-12-12 15:46         ` Ard Biesheuvel
2019-12-13 21:24           ` Matthew Garrett
2019-12-03 18:23 ` kbuild test robot
2019-12-05 13:04 ` kbuild test robot

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on

Archives are clonable:
	git clone --mirror linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ \
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone