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.

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