RE: [PATCH] docs: security: Confidential computing intro and threat model

["Reshetova, Elena" <elena.reshetova@intel.com>]

> On Wed, Apr 26, 2023, Carlos Bilbao wrote:
> > On 4/26/23 2:53 PM, Sean Christopherson wrote:
> > > On Wed, Apr 26, 2023, Carlos Bilbao wrote:
> > >> On 4/26/23 10:51 AM, Sean Christopherson wrote:
> > >>> This document is named confidential-computing.rst, not tdx-and-snp.rst.
> Not
> > >>> explicitly mentioning SEV doesn't magically warp reality to make
> descriptions like
> > >>> this one from security/secrets/coco.rst disappear:
> > >>>
> > >>>   Introduction
> > >>>   ============
> > >>>
> > >>>   Confidential Computing (coco) hardware such as AMD SEV (Secure
> Encrypted
> > >>>   Virtualization) allows guest owners to inject secrets into the VMs
> > >>>   memory without the host/hypervisor being able to read them.
> > >>>
> > >>> My complaint about this document being too Intel/AMD centric isn't that it
> doesn't
> > >>> mention other implementations, it's that the doc describes CoCo purely
> from the
> > >>> narrow viewpoint of Intel TDX and AMD SNP, and to be blunt, reads like a
> press
> > >>> release and not an objective overview of CoCo.
> > >>
> > >> Be specific about the parts of the document that you feel are too
> > >> AMD/Intel centric, and we will correct them.
> > >
> > > The whole thing?  There aren't specific parts that are too SNP/TDX centric, the
> > > entire tone and approach of the document is wrong.  As I responded to Dave,
> I
> > > would feel differently if the document were named tdx-and-snp-threat-
> model.rst,
> > > but this patch proposes a generic confidential-computing.rst and presents the
> > > SNP+TDX confidential VM use case as if it's the *only* confidential computing
> use
> > > case.
> >
> > What part of us describing the current Linux kernel threat model or
> > defining basic concepts of confidential computing is SNP/TDX centric?
> >
> > IMHO, simply stating that "the whole thing" is wrong and that you don't
> > like the "tone", is not making a good enough case for us to change
> > anything, including the name of the document.
> 
> I honestly don't know how to respond since you are either unable or unwilling to
> see the problems with naming a document "confidential computing" and then
> talking
> only about one very, very specific flavor of confidential computing as if that is
> the only flavor of confidential computing.

This is simply an unfair statement. I replied yesterday on this particular angle, i.e.
let's think on how to name this properly: explained our thinking behind using the 
"Confidential Cloud Computing" term (with references to academia using it) and asked
what the better name should be. I didn’t get a reply to that, but here you say we
are not willing to cooperate...

So I don’t think it is fair to say that we don’t take feedback! 

I agree with Dave that I think the goal of this document is not to come up with a
fancy name (I am fine with call it anything), but to introduce kernel developers to the 
new Linux threat model angle for this-particular-use-case-of-confidential-computing.
So that when we submit the hardening mechanisms in the future people are 
already familiar with why we need to do this and we don’t have to repeat this story 
again and again. 

Best Regards,
Elena.