From: Matthew Garrett <firstname.lastname@example.org> To: Laszlo Ersek <email@example.com> Cc: Ard Biesheuvel <firstname.lastname@example.org>, linux-efi <email@example.com>, "the arch/x86 maintainers" <firstname.lastname@example.org>, linux-pci <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org> Subject: Re: [PATCH] [EFI,PCI] Allow disabling PCI busmastering on bridges during boot Date: Tue, 3 Dec 2019 11:36:14 -0800 Message-ID: <CACdnJutpgeUsGcscVJsxsj5-E=0JwYUFqEfjT4VJ+BMjn2RpAQ@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Tue, Dec 3, 2019 at 5:38 AM Laszlo Ersek <firstname.lastname@example.org> wrote: > (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. A malicious PCI device can absolutely set up DMA itself without a matching driver. There's a couple of cases: 1) A device that's entirely under the control of an attacker. Using external Thunderbolt devices to overwrite OS data has been demonstrated on multiple occasions. 2) A device that's been compromised in some way. The UEFI driver is a long way from the only software that's related to the device - discrete GPUs boot themselves even in the absence of a driver, and if that on-board code can be compromised in any persistent way then they can be used to attack the OS. > 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? Yes, though it's not just internal devices that we need to worry about. > (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 > encrypted.) I'm working on that, but it would be nice to have an approach for existing systems.
next prev parent 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 2019-12-03 19:36 ` Matthew Garrett [this message] 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CACdnJutpgeUsGcscVJsxsj5-E=0JwYUFqEfjT4VJ+BMjn2RpAQ@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-PCI Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-pci/0 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/ https://lore.kernel.org/linux-pci \ firstname.lastname@example.org public-inbox-index linux-pci Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci AGPL code for this site: git clone https://public-inbox.org/public-inbox.git