> > > +understanding of the subject. > > + > > +Overview and terminology > > +======================== > > + > > +Confidential Cloud Computing (CoCo) refers to a set of HW and SW > > As per Documentation/security/secrets/coco.rst and every discussion I've observed, > CoCo is Confidential Computing. "Cloud" is not part of the definition. That's > true even if this discussion is restricted to CoCo VMs, e.g. see pKVM. > > > +virtualization technologies that allow Cloud Service Providers (CSPs) to > > Again, CoCo isn't just for cloud use cases. Agreed Cloud should not be included in the definition. pKVM may be considered CoCo and its current usage is protecting secrets on a single device. CoCo features could be used with-in a single organization to add extra protection to high value secrets. > > > +provide stronger security guarantees to their clients (usually referred to > > +as tenants) by excluding all the CSP's infrastructure and SW out of the > > +tenant's Trusted Computing Base (TCB). > > This is inaccurate, the provider may still have software and/or hardware in the TCB. > > And for the cloud use case, I very, very strongly object to implying that the goal > of CoCo is to exclude the CSP from the TCB. Getting out of the TCB is the goal for > _some_ CSPs, but it is not a fundamental tenant of CoCo. This viewpoint is heavily > tainted by Intel's and AMD's current offerings, which effectively disallow third > party code for reasons that have nothing to do with security. > > https://lore.kernel.org/all/Y+aP8rHr6H3LIf%2Fc@xxxxxxxxxx > How about phrasing like "CoCo allows its users to pick and choose which pieces of software system to trust and gives the ability to attest the state of trusted components" Maybe some customers want to exclude or attest to the entire CSP infra and SW. But it seems likely that customers may want to use and trust some components of a CSP. For instance you may enable CoCo on a workload but then trust the CSP's IAM implementation to make sure data only enters those CoCo workloads. > > > +Confidential Computing threat model and security objectives > > +=========================================================== > > + > > +Confidential Cloud Computing adds a new type of attacker to the above list: > > +an untrusted and potentially malicious host. > > I object to splattering "malicious host" everywhere. Many people are going to > read this and interpret "host" as "the CSP", and then make assumptions like > "CoCo assumes the CSP is malicious!". AIUI, the vast majority of use cases aren't > concerned so much about "the CSP" being malicious, but rather they're concerned > about new attack vectors that come with running code/VMs on a stack that is > managed by a third party, on hardware that doesn't reside in a secured facility, > etc. > > > +While the traditional hypervisor has unlimited access to guest data and > > +can leverage this access to attack the guest, the CoCo systems mitigate > > +such attacks by adding security features like guest data confidentiality > > +and integrity protection. This threat model assumes that those features > > +are available and intact. > > Again, if you're claiming integrity is a key tenant, then SEV and SEV-ES can't be > considered CoCo. Hmm the doc mentions "untrusted and potentially malicious host." but seems to take the stance the CoCo requires tech where malicious host deprivelleging is possible. But as Sean points out there may be valid CoCo theat models where the host is trusted, or trusted to be benign like SEV and SEV-ES. I think this doc could use some more nuance so that less strict threat-models are supported. Also in regard to "malicious host" I think we can use this term since that could be a valid threat. And in general I think cloud customers are sophisticated enough to understand that a single lone malicious host is far different than a malicious CSP. CSPs are in general large organizations with many services of which VMs or "enclaves" are only a small part.
