Messages in this thread | | | Date | Wed, 8 Feb 2023 18:02:39 +0000 | From | "Dr. David Alan Gilbert" <> | Subject | Re: Linux guest kernel threat model for Confidential Computing |
| |
* Greg Kroah-Hartman (gregkh@linuxfoundation.org) wrote: > On Wed, Feb 08, 2023 at 05:19:37PM +0100, Christophe de Dinechin wrote: > > > > On 2023-02-08 at 11:58 +01, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote... > > > On Wed, Feb 08, 2023 at 10:44:25AM +0000, Reshetova, Elena wrote: > > >> > > >> The CC threat model does change the traditional linux trust boundary regardless of > > >> what mitigations are used (kernel config vs. runtime filtering). Because for the > > >> drivers that CoCo guest happens to need, there is no way to fix this problem by > > >> either of these mechanisms (we cannot disable the code that we need), unless somebody > > >> writes a totally new set of coco specific drivers (who needs another set of > > >> CoCo specific virtio drivers in the kernel?). > > > > > > It sounds like you want such a set of drivers, why not just write them? > > > We have zillions of drivers already, it's not hard to write new ones, as > > > it really sounds like that's exactly what you want to have happen here > > > in the end as you don't trust the existing set of drivers you are using > > > for some reason. > > > > In the CC approach, the hypervisor is considered as hostile. The rest of the > > system is not changed much. If we pass-through some existing NIC, we'd > > rather use the existing driver for that NIC rather than reinvent > > it. > > But that is not what was proposed. I thought this was all about virtio. > If not, again, someone needs to write a solid definition.
As I said in my reply to you a couple of weeks ago:
I'm not sure the request here isn't really to make sure *all* PCI devices are safe; just the ones we care about in a CoCo guest (e.g. the virtual devices) - and potentially ones that people will want to pass-through (which generally needs a lot more work to make safe). (I've not looked at these Intel tools to see what they cover)
so *mostly* virtio, and just a few of the other devices.
> So if you want to use existing drivers, wonderful, please work on making > the needed changes to meet your goals to all of them. I was trying to > give you a simple way out :) > > > >> 1. these selective CoCo guest required drivers (small set) needs to be hardened > > >> (or whatever word people prefer to use here), which only means that in > > >> the presence of malicious host/hypervisor that can manipulate pci config space, > > >> port IO and MMIO, these drivers should not expose CC guest memory > > >> confidentiality or integrity (including via privilege escalation into CC guest). > > > > > > Again, stop it please with the "hardened" nonsense, that means nothing. > > > Either the driver has bugs, or it doesn't. I welcome you to prove it > > > doesn't :) > > > > In a non-CC scenario, a driver is correct if, among other things, it does > > not leak kernel data to user space. However, it assumes that PCI devices are > > working correctly and according to spec. > > And you also assume that your CPU is working properly.
We require the CPU to give us a signed attestation to prove that it's a trusted CPU, that someone external can validate. So, not quite 'assume'.
> And what spec > exactly are you referring to? How can you validate any of that without > using the PCI authentication protocol already discussed in this thread?
The PCI auth protocol looks promising and is possibly the right long term answer. But for a pass through NIC for example, all we'd want is that (with the help of the IOMMU) it can't get or corrupt any data the guest doesn't give it - and then it's upto the guest to run encryption over the protocols over the NIC.
> > > >> Please note that this only applies to a small set (in tdx virtio setup we have less > > >> than 10 of them) of drivers and does not present invasive changes to the kernel > > >> code. There is also an additional core pci/msi code that is involved with discovery > > >> and configuration of these drivers, this code also falls into the category we need to > > >> make robust. > > > > > > Again, why wouldn't we all want "robust" drivers? This is not anything > > > new here, > > > > What is new is that CC requires driver to be "robust" against a new kind of > > attack "from below" (i.e. from the [virtual] hardware side). > > And as I have said multiple times, that is a totally new "requirement" > and one that Linux does not meet in any way at this point in time.
Yes, that's a fair statement.
> If > you somehow feel this is a change that is ok to make for Linux, you will > need to do a lot of work to make this happen. > > Anyway, you all are just spinning in circles now. I'll just mute this > thread until I see an actual code change as it seems to be full of > people not actually sending anything we can actually do anything with.
I think the challenge will be to come up with non-intrusive, minimal changes; obviously you don't want stuff shutgunned everywhere.
Dave
> greg k-h > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
| |