On Thu, 2023-04-27 at 12:43 +0000, Reshetova, Elena wrote:
>
> > On Wed, Apr 26, 2023, James Bottomley wrote:
> > > On Wed, 2023-04-26 at 13:32 +0000, Reshetova, Elena wrote:
[...]
> > > > the practical deployment can differ of course. We can rephrase
> > > > that it "allows to exclude all the CSP's infrastructure and SW
> > > > out of tenant's TCB."
> > >
> > > That's getting even more inaccurate. To run in a Cloud with
> > > CoCo you usually have to insert some provided code, like OVMF
> > > and, for AMD, the SVSM. These are often customized by the CSP to
> > > suit the cloud infrastructure, so you're running their code. The
> > > goal, I think, is to make sure you only run code you trust (some
> > > of which may come from the CSP) in your TCB, which is very
> > > different from the statement above.
> >
> > Yes. And taking things a step further, if we were to ask security
> > concious users what they would choose to have in their TCB: (a)
> > closed-source firmware written by a hardware vendor, or (b) open-
> > source software that is provided by CSPs, I am betting the
> > overwhelming majority would choose (b).
>
> As I already replied in my earlier message from yesterday, yes, this
> is the choice that anyone has and it is free to make this choice. No
> questions asked. (Btw, please note that the above statement is not
> 100% accurate since the source code for intel TDX module is at least
> public). However, if as you said the majority choose (b), why do they
> need to enable the Confidential cloud computing technologies like TDX
> or SEV-SNP? If they choose (b), then the whole threat model described
> in this document do not simply apply to them and they can forget
> about anything that we try to describe here.
I think the problem is that the tenor of the document is that the CSP
should be seen as the enemy of the tenant. Whereas all CSP's want to be
seen as the partner of the tenant (admittedly so they can upsell
services). In particular, even if you adopt (b) there are several
reasons why you'd use confidential computing:
1. Protection from other tenants who break containment in the cloud.
These tenants could exfiltrate data from Non-CoCo VMs, but likely
would be detected before they had time to launch an attack using
vulnerabilities in the current linux device drivers.
2. Legal data security. There's a lot of value in a CSP being able
to make the legal statement that it does not have access to a
customer data because of CoCo.
3. Insider threats (bribe a CSP admin employee). This one might get
as far as trying to launch an attack on a CoCo VM, but having
checks at the CSP to detect and defeat this would work instead of
every insider threat having to be defeated inside the VM.
In all of those cases (which are not exhaustive) you can regard the CSP
as a partner of the tenant when it comes to preventing and detecting
threats to the CoCo VM, so extreme device driver hardening becomes far
less relevant to these fairly considerable use cases.
> Now from the pure security point of view the choice between (a) and
> (b) is not so easily done imo. Usually we take into account many
> factors that affect the risk/chances that certain piece of SW has a
> higher risk of having vulnerabilities. This includes the size of the
> codebase, its complexity, its attack surface exposure towards
> external interfaces, level of testing, whenever the code is public,
> code dependency chains, etc. Smaller codebase with no dependencies
> and small set of exposed interfaces is usually easier to review from
> security point of view given that the code is public.
This reads like an argument that, from a security point of view,
smaller proprietary code is better than larger, open source, code. I
really don't think we want to open this can of worms. Most industry
players have already bought the idea that open source improves security
because even if you can't rely on the community entirely, you can take
the code to a third party for analysis.
James
