> 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. We didn’t intend this interpretation and it can be certainly be fixed if people see it this way. 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. Not sure how this "likely to be detected" is going to happen in practice. If you have a known vulnerability against a CoCo VM (let say in a device driver interface it exposes), is it so much more difficult for an attacker to break into CoCo VM vs non-CoCo VM before it is detected? > 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. Let's leave legal out of technical discussion, not my area. > 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. Ok, this angle might be valid from CSP point of view, i.e. noticing such insider attacks might be easier I guess with CoCo VMs. > > 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. I think the first case still holds, as well as one case that you have not listed: a remote attacker attacking CSP stack using some discovered and not yet fixed vulnerability (stack is big, bugs happen), getting control of CSP stack and then going after the CoCo VMs to see what it can get there. What you are saying is that you (as CSP) maintain the good first level defense to prevent attacker to get control of your/CSP stack to begin with. What we try to do is the next level of defense (very typical in any security): we assume that first line of defense has been broken for some reason and now there is a second one placed to actually protect customers end data. > > > 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. I don’t think I have made this statement: the code *has to be public* for anyone to review and I did explicitly list this in the statement above as "given that the code is public". Only thing I meant is that it is not not so easy to make a call between (a) and (b) in all cases from a pure security point of view. Best Regards, Elena.
