Message-ID: <DM8PR11MB5750118EECE1BF835CF0393BE7CF9@DM8PR11MB5750.namprd11.prod.outlook.com>
Date:   Thu, 26 Jan 2023 13:13:13 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>
CC:     "Shishkin, Alexander" <alexander.shishkin@...el.com>,
        "Shutemov, Kirill" <kirill.shutemov@...el.com>,
        "Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "Wunner, Lukas" <lukas.wunner@...el.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        "Poimboe, Josh" <jpoimboe@...hat.com>,
        "aarcange@...hat.com" <aarcange@...hat.com>,
        Cfir Cohen <cfir@...gle.com>, Marc Orr <marcorr@...gle.com>,
        "jbachmann@...gle.com" <jbachmann@...gle.com>,
        "pgonda@...gle.com" <pgonda@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        James Morris <jmorris@...ei.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        "Lange, Jon" <jlange@...rosoft.com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: Linux guest kernel threat model for Confidential Computing


> > > I hate the term "hardening".  Please just say it for what it really is,
> > > "fixing bugs to handle broken hardware".  We've done that for years when
> > > dealing with PCI and USB and even CPUs doing things that they shouldn't
> > > be doing.  How is this any different in the end?
> > >
> > > So what you also are saying here now is "we do not trust any PCI
> > > devices", so please just say that (why do you trust USB devices?)  If
> > > that is something that you all think that Linux should support, then
> > > let's go from there.
> >
> > I don't think generally all PCI device drivers guard against all the
> > nasty things that a broken implementation of their hardware can do.
> 
> I know that all PCI drivers can NOT do that today as that was never
> anything that Linux was designed for.
> 
> > The USB devices are probably a bit better, because they actually worry
> > about people walking up with a nasty HID device;  I'm skeptical that
> > a kernel would survive a purposely broken USB controller.
> 
> I agree with you there, USB drivers are only starting to be fuzzed at
> the descriptor level, that's all.  Which is why they too can be put into
> the "untrusted" area until you trust them.
> 
> > 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)
> 
> Why not just create a whole new bus path for these "trusted" devices to
> attach to and do that instead of tyring to emulate a protocol that was
> explicitly designed NOT to this model at all?  Why are you trying to
> shoehorn something here and not just designing it properly from the
> beginning?
> 
> > Having said that, how happy are you with Thunderbolt PCI devices being
> > plugged into your laptop or into the hotplug NVMe slot on a server?
> 
> We have protection for that, and have had it for many years.  Same for
> USB devices.  This isn't new, perhaps you all have not noticed those
> features be added and taken advantage of already by many Linux distros
> and system images (i.e. ChromeOS and embedded systems?)
> 
> > We're now in the position we were with random USB devices years ago.
> 
> Nope, we are not, again, we already handle random PCI devices being
> plugged in.  It's up to userspace to make the policy decision if it
> should be trusted or not before the kernel has access to it.
> 
> So a meta-comment, why not just use that today?  If your guest OS can
> not authenticate the PCI device passed to it, don't allow the kernel to
> bind to it.  If it can be authenticated, wonderful, bind away!  You can
> do this today with no kernel changes needed.
> 
> > Also we would want to make sure that any config data that the hypervisor
> > can pass to the guest is validated.
> 
> Define "validated" please.
> 
> > The problem seems reasonably well understood within the CoCo world - how
> > far people want to push it probably varies; but it's good to make the
> > problem more widely understood.
> 
> The "CoCo" world seems distant and separate from the real-world of Linux
> kernel development if you all do not even know about the authentication
> methods that we have for years for enabling access to PCI and USB
> devices as described above.  If the impementations that we currently
> have are lacking in some way, wonderful, please submit changes for them
> and we will be glad to review them as needed.

We are aware of USB/Thunderbolt authorization framework and this is what we have
been extending now for the our CC usage in order to apply this to all devices.
The patches are currently under testing/polishing, but we will be submitting
them in the near future. 

That's said even with the above in place we don’t get a protection from a man-in-
the-middle attacks that are possible by untrusted hypervisor or host. In order
to get a full protection here, we need an attestation and end-to-end secure channel
between devices and CC guest. However, since it is going to take a long time before
we have all the infrastructure in place in Linux, as well as devices that are capable of
supporting all required functionality (and some devices will never have this support such
as virtual devices), we need to have a reasonable security model now, vs waiting 
until researchers are starting to post the proof-of-concept privilege escalation exploits
on smth that is even (thanks to the tools we created in in [1]) not so hard to find:
you run our fuzzing  tools on the guest kernel tree of your liking and it gives you a nice set
of KASAN issues to play with. What we are trying to do is to address these findings (among
other things) for a more robust guest kernel.

Best Regards,
Elena

[1] https://github.com/intel/ccc-linux-guest-hardening
 

Powered by blists - more mailing lists