[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SecureBoot and PCI passthrough with kernel lockdown in place (on Xen
From: |
address@hidden |
Subject: |
Re: SecureBoot and PCI passthrough with kernel lockdown in place (on Xen) |
Date: |
Mon, 14 Feb 2022 16:33:31 +0100 |
On Mon, Feb 14, 2022 at 03:25:31PM +0000, Andrew Cooper wrote:
> On 14/02/2022 15:02, Dario Faggioli wrote:
> > Hello,
> >
> > We have run into an issue when trying to use PCI passthrough for a Xen
> > VM running on an host where dom0 kernel is 5.14.21 (but we think it
> > could be any kernel > 5.4) and SecureBoot is enabled.
>
> Back up a bit...
>
> Xen doesn't support SecureBoot and there's a massive pile of work to
> make it function, let alone work in a way that MSFT aren't liable to
> revoke your cert on 0 notice.
>
> >
> > The error we get, when (for instance) trying to attach a device to an
> > (HVM) VM, on such system is:
> >
> > # xl pci-attach 2-fv-sles15sp4beta2 0000:58:03.0
> > libxl: error: libxl_qmp.c:1838:qmp_ev_parse_error_messages: Domain
> > 12:Failed to initialize 12/15, type = 0x1, rc: -1
> > libxl: error: libxl_pci.c:1777:device_pci_add_done: Domain
> > 12:libxl__device_pci_add failed for PCI device 0:58:3.0 (rc -28)
> > libxl: error: libxl_device.c:1420:device_addrm_aocomplete: unable to add
> > device
> >
> > QEMU, is telling us the following:
> >
> > [00:04.0] xen_pt_msix_init: Error: Can't open /dev/mem: Operation not
> > permitted
> > [00:04.0] xen_pt_msix_size_init: Error: Internal error: Invalid
> > xen_pt_msix_init.
> >
> > And the kernel reports this:
> >
> > Jan 27 16:20:53 narvi-sr860v2-bps-sles15sp4b2 kernel: Lockdown:
> > qemu-system-i38: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
> >
> > So, it's related to lockdown. Which AFAIUI it's consistent with the
> > fact that the problem only shows up when SecureBoot is enabled, as
> > that's implies lockdown. It's also consistent with the fact that we
> > don't seem to have any problems doing the same with a 5.3.x dom0
> > kernel... As there's no lockdown there!
> >
> > Some digging revealed that QEMU tries to open /dev/mem in
> > xen_pt_msix_init():
> >
> > fd = open("/dev/mem", O_RDWR);
> > ...
> > msix->phys_iomem_base =
> > mmap(NULL,
> > total_entries * PCI_MSIX_ENTRY_SIZE +
> > msix->table_offset_adjust,
> > PROT_READ,
> > MAP_SHARED | MAP_LOCKED,
> > fd,
> > msix->table_base + table_off - msix->table_offset_adjust);
> > close(fd);
>
> Yes. Use of /dev/mem is not permitted in lockdown mode. This wants
> reworking into something which is lockdown compatible.
FWIW, Qubes has PCI passthrough working with qemu in stubdomain, which
works without access to /dev/mem in dom0. We do this, by disabling
MSI-X, including the above piece of code...
https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/blob/master/qemu/patches/0005-Disable-MSI-X-caps.patch
> The real elephant in the room is that privcmd is not remotely safe to
> use in a SecureBoot environment, because it lets any root userspace
> trivially escalate privilege into the dom0 kernel, bypassing the
> specific protection that SecureBoot is trying to achieve.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature