Re: Linux guest kernel threat model for Confidential Computing

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Feb 08, 2023 at 10:44:25AM +0000, Reshetova, Elena wrote:
> 
> 
> > On Tue, Feb 07, 2023 at 08:51:56PM -0500, Theodore Ts'o wrote:
> > > Why not just simply compile a special CoCo kernel that doesn't have
> > > any drivers that you don't trust.
> 
> Aside from complexity and scalability management of such a config that has
> to change with every kernel release, what about the build-in platform drivers?

What do you mean by "built in platform drivers"?  You are creating a
.config for a specific cloud platform, just only select the drivers for
that exact configuration and you should be fine.

And as for the management of such a config, distros do this just fine,
why can't you?  It's not that hard to manage properly.

> I am not a driver expert here but as far as I understand they cannot be disabled
> via config. Please correct if this statement is wrong. 

Again, which specific drivers are you referring to?  And why are they a
problem?

> > In order to make $$$$$, you need to push the costs onto various
> > different players in the ecosystem.  This is cleverly disguised as
> > taking current perfectly acceptable design paradigm when the trust
> > boundary is in the traditional location, and causing all of the
> > assumptions which you have broken as "bugs" that must be fixed by
> > upstream developers.
> 
> 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.

> So, if the path is to be able to use existing driver kernel code, then we need:

Wait, again, why?  Why not just have your own?  That should be the
simplest thing overall.  What's wrong with that?

> 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 :)

> 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, all you are somehow saying is that you are changing the thread
model that the kernel "must" support.  And for that, you need to then
change the driver code to support that.

So again, why not just have your own drivers and driver subsystem that
meets your new requirements?  Let's see what that looks like and if
there even is any overlap between that and the existing kernel driver
subsystems.

> 2. rest of non-needed drivers must be disabled. Here we can argue about what 
> is the correct method of doing this and who should bare the costs of enforcing it. 

You bare that cost.  Or you get a distro to do that.  That's not up to
us in the kernel community, sorry, we give you the option to do that if
you want to, that's all that we can do.

> But from pure security point of view: the method that is simple and clear, that
> requires as little maintenance as possible usually has the biggest chance of
> enforcing security. 

Again, that's up to your configuration management.  Please do it, tell
us what doesn't work and send changes if you find better ways to do it.
Again, this is all there for you to do today, nothing for us to have to
do for you.

> And given that we already have the concept of authorized devices in Linux,
> does this method really brings so much additional complexity to the kernel? 

No idea, you tell us!  :)

Again, I recommend you just having your own drivers, that will allow you
to show us all exactly what you mean by the terms you keep using.  Why
not just submit that for review instead?

good luck!

greg k-h