Jason Gunthorpe wrote: > 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. Yes, especially if there are ongoing memory conversions. > > 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. > > From what I can see on some platforms/configurations if the device is > trusted capable then it MUST only issue trusted DMA as that is the > only IO translation that will work. Given that PCI defines that devices can fall out of "trusted capable" mode that implies there needs to be an error recovery path. For at least the platforms I am looking at (SEV, TDX, COVE) a "convert device to private operation" step is a possibility after the TVM is already running. Are you implying that this platform in question would need to shutdown the TVM and start over if, for example, the encrypted link state bounced? Or maybe device capability conversions are effectively "replug" events on such a host? > Meaning the decision to operate a device as trusted or not really has > to be done before any driver is probed and probably needs to involve > the iommu layer to try and do something about this mess in some way. Yes, userspace needs to be able to deploy device-attestation policy prior to driver attach. > I have yet to see a complete plan for how these details should work :) There are so many details that I find myself needing to land basic infrastructure upstream to bound the possibility space. > And I only know in detail how the iommu works for one platform, not > the others, so I don't know how prevalent these concerns are.. I think it is an important concern. Even if there is a dynamic "convert device to private" capability, there is a question about what happens to ongoing page conversions. Simultaneous untrusted / trusted memory access may end up being something devices want, but not all host platforms can offer.
