All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	Matthew Garrett <mjg59@google.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot
Date: Mon, 23 Dec 2019 10:46:49 -0500	[thread overview]
Message-ID: <20191223154648.GA10522@rani.riverdale.lan> (raw)
In-Reply-To: <CAKv+Gu-PmOo6mvaBELjxj=9hbLynidt4Yf_qyr6m9db=6SS7vw@mail.gmail.com>

On Mon, Dec 23, 2019 at 03:02:40PM +0100, Ard Biesheuvel wrote:
> 
> Practically, on PCIe systems, PCI/PCI bridges are the only thing we
> need to care about, since that is how PCIe root ports are modelled.

If I'm interpreting my lspci output correctly, I have a PCI/ISA bridge
on bus 0 that's not behind a PCI/PCI bridge. Device 1f.0 below is the
PCI/ISA bridge. Devices 1-3 are the CPU root ports and 1c.* are the
chipset root ports.

Also, what about for eg, the USB or SATA controllers? I know that
someone had said earlier that disabling BM on endpoints is pointless as
malicious endpoints could just re-enable it, but is it not possible for
malicious USB devices/SATA devices to try to use DMA through those
controllers? ie if we trust the controllers since they're on-board, but
not necessarily the devices behind them, wouldn't it still be worth it
to disable BM on the controllers too?

$ lspci -tv -s 0:0:
-[0000:00]-+-00.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D DMI2
           +-01.0-[01]--
           +-01.1-[02]--
           +-02.0-[03]--
           +-02.2-[04]--
           +-03.0-[05]--
           +-03.2-[06-09]--
           +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D Map/VTd_Misc/System Management
           +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D IIO Hot Plug
           +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D IIO RAS/Control Status/Global Errors
           +-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D I/O APIC
           +-11.0  Intel Corporation C610/X99 series chipset SPSR
           +-11.4  Intel Corporation C610/X99 series chipset sSATA Controller [AHCI mode]
           +-14.0  Intel Corporation C610/X99 series chipset USB xHCI Host Controller
           +-16.0  Intel Corporation C610/X99 series chipset MEI Controller #1
           +-16.1  Intel Corporation C610/X99 series chipset MEI Controller #2
           +-1a.0  Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #2
           +-1b.0  Intel Corporation C610/X99 series chipset HD Audio Controller
           +-1c.0-[0a]--
           +-1c.2-[0b]--
           +-1c.3-[0c]--
           +-1c.4-[0d]--
           +-1c.7-[0e-0f]--
           +-1d.0  Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #1
           +-1f.0  Intel Corporation C610/X99 series chipset LPC Controller
           +-1f.2  Intel Corporation C610/X99 series chipset 6-Port SATA Controller [AHCI mode]
           \-1f.3  Intel Corporation C610/X99 series chipset SMBus Controller


  reply	other threads:[~2019-12-23 15:46 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 17:01 [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 01/21] efi/libstub: remove unused __efi_call_early() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 02/21] efi/x86: rename efi_is_native() to efi_is_mixed() Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 03/21] efi/libstub: use a helper to iterate over a EFI handle array Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 04/21] efi/libstub: extend native protocol definitions with mixed_mode aliases Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 05/21] efi/libstub: distinguish between native/mixed not 32/64 bit Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 06/21] efi/libstub/x86: use mixed mode helpers to populate efi_config Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 07/21] efi/libstub: drop explicit 32/64-bit protocol definitions Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 08/21] efi/libstub: use stricter typing for firmware function pointers Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 09/21] efi/libstub: annotate firmware routines as __efiapi Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 10/21] efi/libstub/x86: avoid thunking for native firmware calls Ard Biesheuvel
2019-12-21 21:22   ` Hans de Goede
2019-12-22 12:02     ` Ard Biesheuvel
2019-12-22 12:37       ` Ard Biesheuvel
2019-12-22 12:46       ` Andy Lutomirski
2019-12-22 15:29         ` Ard Biesheuvel
2019-12-22 21:12           ` Arvind Sankar
2019-12-22 21:25             ` Ard Biesheuvel
2019-12-23 11:49       ` Hans de Goede
2019-12-23 12:00         ` Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 11/21] efi/libstub: get rid of 'sys_table_arg' macro parameter Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 12/21] efi/libstub: unify the efi_char16_printk implementations Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 13/21] efi/libstub/x86: drop __efi_early() export of efi_config struct Ard Biesheuvel
2019-12-24 19:34   ` Hans de Goede
2019-12-25 14:42     ` Ard Biesheuvel
2019-12-27 22:44       ` Hans de Goede
2019-12-27 22:51         ` Ard Biesheuvel
2019-12-31 23:04   ` Arvind Sankar
2020-01-01 18:13     ` Ard Biesheuvel
2020-01-01 19:08       ` Arvind Sankar
2020-01-02  7:33         ` Ard Biesheuvel
2020-01-02 14:06           ` Arvind Sankar
2020-01-02 15:20             ` Ard Biesheuvel
2020-01-02 15:51               ` Arvind Sankar
2020-01-02 15:58                 ` Ard Biesheuvel
2020-01-02 16:28                   ` Ard Biesheuvel
2020-01-02 16:59                     ` Ard Biesheuvel
2020-01-02 17:26                       ` Arvind Sankar
2020-01-02 17:30                         ` Ard Biesheuvel
2020-01-02 17:41                           ` Arvind Sankar
2020-01-02 17:48                             ` Ard Biesheuvel
2020-01-02 18:10                               ` Arvind Sankar
2020-01-02 18:38                                 ` Ard Biesheuvel
2020-01-03 14:16                                   ` Arvind Sankar
2020-01-03 14:23                                     ` Ard Biesheuvel
2020-01-02 18:38                               ` Arvind Sankar
2020-01-02 16:59                     ` Arvind Sankar
2020-01-02 17:03                       ` Ard Biesheuvel
2020-01-02 17:21                         ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 14/21] efi/libstub: drop sys_table_arg from printk routines Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 15/21] efi/libstub: remove 'sys_table_arg' from all function prototypes Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 16/21] efi/libstub: drop protocol argument from efi_call_proto() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 17/21] efi/libstub: drop 'table' argument from efi_table_attr() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 18/21] efi/libstub: use 'func' not 'f' as macro parameter Ard Biesheuvel
2019-12-31 16:51   ` Arvind Sankar
2019-12-31 17:06     ` Ard Biesheuvel
2019-12-31 17:36       ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 19/21] efi/libstub: tidy up types and names of global cmdline variables Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 20/21] efi/libstub: import type definitions for creating and signalling events Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot Ard Biesheuvel
2019-12-19  2:50   ` Andy Lutomirski
2019-12-19 13:17     ` Ard Biesheuvel
2019-12-19 20:04       ` Matthew Garrett
2019-12-19 20:04   ` Matthew Garrett
2019-12-20  7:06     ` Ard Biesheuvel
2019-12-20  7:17       ` Andy Lutomirski
2019-12-20  8:11         ` Ard Biesheuvel
2019-12-20 19:41           ` Arvind Sankar
2020-01-02 14:46             ` Laszlo Ersek
2020-01-02 15:40               ` Ard Biesheuvel
2019-12-20 20:43       ` Matthew Garrett
2019-12-21 16:44         ` Ard Biesheuvel
2019-12-21 21:24           ` Matthew Garrett
2019-12-21 22:54             ` Arvind Sankar
2019-12-23 14:02               ` Ard Biesheuvel
2019-12-23 15:46                 ` Arvind Sankar [this message]
2019-12-23 15:58                   ` Ard Biesheuvel
2019-12-23 16:12                     ` Arvind Sankar
2019-12-23 20:57                   ` Matthew Garrett
2020-02-06 14:30   ` Hans de Goede
2020-02-06 14:35     ` Ard Biesheuvel
2020-03-04 10:38       ` Hans de Goede
2020-03-04 18:26         ` Ard Biesheuvel
2020-03-04 18:49           ` Hans de Goede
2020-03-04 21:59             ` Ard Biesheuvel
2019-12-19 11:12 ` [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Hans de Goede
2019-12-19 13:22   ` Ard Biesheuvel

Reply instructions:

You may reply publicly 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=20191223154648.GA10522@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mjg59@google.com \
    --cc=tglx@linutronix.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.