[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB5750678B5F639F6C2848FC3CE7CC9@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Fri, 27 Jan 2023 08:52:22 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "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>,
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>, Kernel Hardening
<kernel-hardening@...ts.openwall.com>
Subject: RE: Linux guest kernel threat model for Confidential Computing
> On Wed, Jan 25, 2023 at 03:29:07PM +0000, Reshetova, Elena wrote:
> > And this is a very special aspect of 'hardening' since it is about hardening a
> kernel
> > under different threat model/assumptions.
>
> I am not sure it's that special in that hardening IMHO is not a specific
> threat model or a set of assumptions. IIUC it's just something that
> helps reduce severity of vulnerabilities. Similarly, one can use the CC
> hardware in a variety of ways I guess. And one way is just that -
> hardening linux such that ability to corrupt guest memory does not
> automatically escalate into guest code execution.
I am not sure if I fully follow you on this. I do agree that it is in principle
the same 'hardening' that we have been doing in Linux for decades just
applied to a new attack surface, host <-> guest, vs userspace <->kernel.
Interfaces have changed, but the types of vulnerabilities, etc are the same.
The attacker model is somewhat different because we have
different expectations on what host/hypervisor should be able to do
to the guest (following business reasons and use-cases), versus what we
expect normal userspace being able to "do" towards kernel. The host and
hypervisor still has a lot of control over the guest (ability to start/stop it,
manage its resources, etc). But the reasons behind this doesn’t come
from the fact that security CoCo HW not being able to support this stricter
security model (it cannot now indeed, but this is a design decision), but
from the fact that it is important for Cloud service providers to retain that
level of control over their infrastructure.
>
> If you put it this way, you get to participate in a well understood
> problem space instead of constantly saying "yes but CC is special". And
> further, you will now talk about features as opposed to fixing bugs.
> Which will stop annoying people who currently seem annoyed by the
> implication that their code is buggy simply because it does not cache in
> memory all data read from hardware. Finally, you then don't really need
> to explain why e.g. DoS is not a problem but info leak is a problem - when
> for many users it's actually the reverse - the reason is not that it's
> not part of a threat model - which then makes you work hard to define
> the threat model - but simply that CC hardware does not support this
> kind of hardening.
But this won't be correct statement, because it is not limitation of HW, but the
threat and business model that Confidential Computing exists in. I am not
aware of a single cloud provider who would be willing to use the HW that
takes the full control of their infrastructure and running confidential guests,
leaving them with no mechanisms to control the load balancing, enforce
resource usage, etc. So, given that nobody needs/willing to use such HW,
such HW simply doesn’t exist.
So, I would still say that the model we operate in CoCo usecases is somewhat
special, but I do agree that given that we list a couple of these special assumptions
(over which ones we have no control or ability to influence, none of us are business
people), then the rest becomes just careful enumeration of attack surface interfaces
and break up of potential mitigations.
Best Regards,
Elena.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
