On Fri, 20 Dec 2019 at 22:43, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
>
> On Thu, Dec 19, 2019 at 11:07 PM Ard Biesheuvel
> <ard.biesheuvel@xxxxxxxxxx> wrote:
> >
> > On Thu, 19 Dec 2019 at 22:05, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Dec 18, 2019 at 9:03 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > > > + status = efi_call_early(create_event, EVT_SIGNAL_EXIT_BOOT_SERVICES,
> > > > + TPL_CALLBACK, handle_exit_boot_services_event,
> > > > + NULL, &exit_boot_services_event);
> > > > + if (status != EFI_SUCCESS) {
> > > > + pr_efi_err("Failed to register for EBS() event\n");
> > > > + goto free_handle;
> > > > + }
> > >
> > > OVMF's SEV implementation appears to tear down AMD's IOMMU mappings at
> > > EVT_SIGNAL_EXIT_BOOT_SERVICES. How are we ensuring that this happens
> > > first?
> >
> > It doesn't, and that is kind of the point. The only guarantee you have
> > is that this runs before ExitBootServices() returns, but after any
> > other callbacks that have been registered. I know this is not 100%
> > what you're after, but it is the only way we can avoid poking devices
> > behind the backs of their drivers.
>
> Hm. In that case, I think this version fails to match the patch
> description - there's potentially still a window where DMA-capable PCI
> devices can attack the kernel, it's just smaller. If disconnecting
> drivers from the device would give us the same expectations then that
> seems like a better approach, but I think I probably wouldn't add my
> signed-off-by to this version.
Point taken. I like Arvind's suggestion but we need to take care not
to disable the device producing the GOP. Beyond that, it should be
possible to disable all devices that are behind PCI bridges. It does
mean we need to decode the secondary/subordinate bus values from the
config space and take them into account when iterating over the PCI
handle list.
