On Mon, Jul 15, 2024 at 01:36:32PM -0700, Dan Williams wrote: > Jason Gunthorpe wrote: > > On Mon, Jul 15, 2024 at 10:21:48AM -0700, Kees Cook wrote: > > > > > Anyway, following the threat model, it doesn't seem like half measures > > > make any sense. If the threat model is "we cannot trust bus members" and > > > authentication is being used to establish trust, then anything else must > > > be explicitly excluded. If this can only be done via the described > > > firewalling, then that really does seem to be the right choice. > > > > There is supposed to be a state machine here, devices start up at VM > > time 0 unable to DMA to secure guest memory under any conditions. This > > property must be enforced by the trusted platform. > > > > Further the trusted plaform is supposed to prevent "replacement" > > attacks, so once the VM says it trusts a device it cannot be replaced > > with something else. > > > > When the guest decides it would like the device to reach secure memory > > the trusted platform is part of making that happen. > > > > From a kernel and lifecycle perspective we need a bunch of new options > > for PCI devices that should be triggered after userspace has had a > > look at the device. > > > > - A device is just forbidden from anything using it > > - A device used only with untrusted memory > > - A device is usable with trusted memory > > > > IMHO this determination needs to be made before the device driver is > > bound. > > Yes, and it depends on the device. Some devices should be filtered > early, some devices need to be operated against untrusted memory just > to get to the point where they can complete the acceptance flow into the > TCB. Operating a device with both trusted and untrusted iommu configurations is complex to manage and depends on how the trusted iommu HW works. > The motivation for the security policy is "there is trusted memory to > protect". Absent trusted memory, the status quo for the device-driver > model applies.
