[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB57505481B2FE79C3D56C9201E7CE9@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 25 Jan 2023 12:28:13 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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: Linux guest kernel threat model for Confidential Computing
Hi Greg,
You mentioned couple of times (last time in this recent thread:
https://lore.kernel.org/all/Y80WtujnO7kfduAZ@kroah.com/) that we ought to start
discussing the updated threat model for kernel, so this email is a start in this direction.
(Note: I tried to include relevant people from different companies, as well as linux-coco
mailing list, but I hope everyone can help by including additional people as needed).
As we have shared before in various lkml threads/conference presentations
([1], [2], [3] and many others), for the Confidential Computing guest kernel, we have a
change in the threat model where guest kernel doesn’t anymore trust the hypervisor.
This is a big change in the threat model and requires both careful assessment of the
new (hypervisor <-> guest kernel) attack surface, as well as careful design of mitigations
and security validation techniques. This is the activity that we have started back at Intel
and the current status can be found in
1) Threat model and potential mitigations:
https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html
2) One of the described in the above doc mitigations is "hardening of the enabled
code". What we mean by this, as well as techniques that are being used are
described in this document:
https://intel.github.io/ccc-linux-guest-hardening-docs/tdx-guest-hardening.html
3) All the tools are open-source and everyone can start using them right away even
without any special HW (readme has description of what is needed).
Tools and documentation is here:
https://github.com/intel/ccc-linux-guest-hardening
4) all not yet upstreamed linux patches (that we are slowly submitting) can be found
here: https://github.com/intel/tdx/commits/guest-next
So, my main question before we start to argue about the threat model, mitigations, etc,
is what is the good way to get this reviewed to make sure everyone is aligned?
There are a lot of angles and details, so what is the most efficient method?
Should I split the threat model from https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html
into logical pieces and start submitting it to mailing list for discussion one by one?
Any other methods?
The original plan we had in mind is to start discussing the relevant pieces when submitting the code,
i.e. when submitting the device filter patches, we will include problem statement, threat model link,
data, alternatives considered, etc.
Best Regards,
Elena.
[1] https://lore.kernel.org/all/20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com/
[2] https://lpc.events/event/16/contributions/1328/
[3] https://events.linuxfoundation.org/archive/2022/linux-security-summit-north-america/program/schedule/
Powered by blists - more mailing lists