On Sun, Aug 03, 2025 at 02:30:00AM +0200, Alexander Bluhm wrote:
> On Sat, Aug 02, 2025 at 02:50:50PM -0600, Theo de Raadt wrote:
> > I am still pretty bewildered at this.
> >
> > +       NULL, "acpi", DV_DULL, CD_SEVVM
> >
> > So you will trust acpi, all the AML tables, and you trust our AML parsing
> > and interpretation code in sys/dev/acpi to do the right thing.  (That is
> > really dubious)
> >
> > You also trust pci and ppb.
> >
> > But if some pci device gets attached on the bus, you are way more
> > worried about the match and attach code in it's driver...?  Most are
> > not going to be used except after ifconfig, or disklabel/mount.
> >
> > Maybe this is about non-pci devices?
> >
> > Can you explain what driver-code you scared of?  Some examples would help.
>
> This diff is far away from making confidential computing secure
> from an evil hypervisor.  Making the acpi driver immune to attacks
> by emulated hardware will be the hardest part, if possible at all.
>
> At the same time, this approach reduces the attack surface from 500
> drivers in generic kernel to 22.  For guests running only on vmm/vmd
> it would be less, but for KVM/qemu these 22 drivers are more or
> less needed.
>

"perfect" being the enemy of "better" here.

I think the new diff is much better than the first proposal, and the group
discussed this quite a bit yesterday. I don't see a problem with the
approach of using the unhibernate-style attach mechanism proposed.

Fixing the actual drivers of course (as bluhm describes below) is a different
effort.

> It also solves some practical issues when running with SEV-ES:
> - When starting vmd(8) in KMV/qemu guest, the kernel panics.
>   Nested SEV is not possible, or at least needs a lot of implementation
>   to somehow run.  Better disable vmm(4) for now.
> - If KVM/qemu emulates USB 2.0, ehci(4) attach crashes during boot.
>   I guess some bus dma sync with bounce buffer is missing in USB
>   stack.  Either fix the driver, or configure qemu accordingly,
>   or disable ehci(4).
> - KVM/qemu emulates vga(4) by default.  When our kernel is probing
>   VGA hardware, we need additional code in VC# trap handler.  This
>   handler would then also need an implementation in vmd(8).  Disabling
>   vga(4) is much easier than supporting a device we don't need in
>   confidential computing.
>
> Theses are just examples we have seen so far.  Having a device list
> of 22 drivers we must support, helps us to concentrate our effort
> on them.
>
> bluhm
>