Re: [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2/6/20 3:35 PM, Ard Biesheuvel wrote:
On Thu, 6 Feb 2020 at 14:31, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:

Hi,

On 12/18/19 6:01 PM, Ard Biesheuvel wrote:
From: Matthew Garrett <matthewgarrett@xxxxxxxxxx>

Add an option to disable the busmaster bit in the control register on
all PCI bridges during the invocation of 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.

If CONFIG_EFI_DISABLE_PCI_DMA is enabled or the "efi=disable_pci_dma"
command line argument is passed, the EFI stub will clear the busmaster
bit on all PCI bridges before ExitBootServices() completes. This will
prevent any malicious PCI devices from being able to perform DMA until
the kernel reenables busmastering after configuring the IOMMU.

This option is disabled when in EFI mixed mode environments (ie, 64-bit
kernels with a 32-bit EFI implementation), given that the use of EFI
events is not supported in this case.

This option may cause failures with some poorly behaved hardware and
should not be enabled without testing. The kernel commandline options
"efi=disable_pci_dma" or "efi=no_disable_pci_dma" may be used to
override the default.

Co-developed-by: Matthew Garrett <mjg59@xxxxxxxxxx>
Signed-off-by: Matthew Garrett <mjg59@xxxxxxxxxx>
[ardb: use EFI events to defer DMA disabling to the end of ExitBootServices()]
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>

I guess this might not be the latest version of this patch, but
this does seem to be the thread where most discussion on it
has happened.

My personal kernel tree atm consists of v5.5 + efi/next + my own patches
and yesterday I noticed that will not boot on a Lenovo X1 7th gen connected
to a Lenovo thunderbolt 3 gen 2 dock.

My first hunch was that I have CONFIG_EFI_DISABLE_PCI_DMA=y and that that
was causing it and indeed that is the problem.

So as (somewhat) expected CONFIG_EFI_DISABLE_PCI_DMA=y indeed stops the kernel
from booting on some systems.

When I hit this problem the efistub prints 2 messages and then the system
just hangs:

exit_boot() failed!
efi_main() failed!

When I boot the system without it being connected to the thunderbolt dock
then efi=disable_pci_dma works fine.

Let me know if I can do anything to help and getting booting while
connected to the dock to work with efi=disable_pci_dma.


Thanks Hans.

Can you run the UEFI shell on this system? If so, could you share the
output of devtree, both in the docked and the undocked states?

That should help us pinpoint which device is throwing an error at
ExitBootServices() time due to its driver having been disconnected.

Sorry for being slow to respond. Attached are the outputs of devtree in
both states. Not sure if the list will accept this, but you should
get a direct copy.

Regards,

Hans

Attachment: devtree-docked
Description: Binary data

Attachment: devtree-not-docked
Description: Binary data


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux