lkml.org 
[lkml]   [2023]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2023-03-27 00:15    [W:4.299 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site