On Mon, Jun 12, 2023, Carlos Bilbao wrote: > Kernel developers working on confidential computing for virtualized > environments in x86 operate under a set of assumptions regarding the Linux No, "x86" isn't special, SNP and TDX and s390's UV are special. pKVM is similar, but (a) it's not as paranoid as SNP and TDX, and (b) the known use case for pKVM on x86 is to harden usage of hardware devices, i.e. pKVM x86 "guests" likely don't have the same "untrusted virtual device" attack surfaces a SNP/TDX/UV guests. > +Kernel developers working on confidential computing for virtualized > +environments in x86 operate under a set of assumptions regarding the Linux I don't think "virtualized environments" is the right description. IMO, "cloud computing environments" or maybe "off-premise environments" more accurately captures what you want to document, though the latter fails to imply the "virtual" aspect of things. > +The specific details of the CoCo security manager vastly diverge between > +technologies. For example, in some cases, it will be implemented in HW > +while in others it may be pure SW. In some cases, such as for the > +`Protected kernel-based virtual machine (pKVM) <https://github.com/intel-staging/pKVM-IA>`, > +the CoCo security manager is a small, isolated and highly privileged > +(compared to the rest of SW running on the host) part of a traditional > +VMM. I say that "virtualized environments" isn't a good description because while pKVM does utilize hardware virtualization, my understanding is that the primary use cases for pKVM don't have the same threat model as SNP/TDX, e.g. IIUC many (most? all?) pKVM guests don't require network access. > +Confidential Computing adds a new type of attacker to the above list: a This should be qualified as "CoCo for cloud", or whatever sublabel we land on. > +potentially misbehaving host (which can also include some part of a > +traditional VMM or all of it), which is typically placed outside of the > +CoCo VM TCB due to its large SW attack surface. It is important to note > +that this doesn’t imply that the host or VMM are intentionally > +malicious, but that there exists a security value in having a small CoCo > +VM TCB. This new type of adversary may be viewed as a more powerful type > +of external attacker, as it resides locally on the same physical machine > +-in contrast to a remote network attacker- and has control over the guest > +kernel communication with most of the HW:: IIUC, this last statement doesn't hold true for the pKVM on x86 use case, which specifically aims to give a "guest" exclusive access to hardware resources. > +The **Linux kernel CoCo VM security objectives** can be summarized as follows: > + > +1. Preserve the confidentiality and integrity of CoCo guest's private > +memory and registers. As I complained in v1, this doesn't hold true for all of x86. My complaint goes away if the document is specific to the TDX/SNP/UV threat models, but describing the doc as "x86 specific" is misleading, as the threat model isn't x86 specific, nor do all confidential compute technologies that run on x86 share these objectives, e.g. vanilla SEV. > +well as CoCo technology specific hypercalls, if present. Additionally, the > +host in a CoCo system typically controls the process of creating a CoCo > +guest: it has a method to load into a guest the firmware and bootloader > +images, the kernel image together with the kernel command line. All of this > +data should also be considered untrusted until its integrity and > +authenticity is established via attestation. Attestation is SNP and TDX specific. AIUI, none of SEV, SEV-ES, or pKVM (which doesn't even really exist on x86 yet), have attestation of their own, e.g. the proposed pKVM support would rely on Secure Boot of the original "full" host kernel. > +CONFIDENTIAL COMPUTING THREAT MODEL FOR X86 VIRTUALIZATION > +M: Elena Reshetova <elena.reshetova@xxxxxxxxx> > +M: Carlos Bilbao <carlos.bilbao@xxxxxxx> > +S: Maintained > +F: Documentation/security/x86-confidential-computing.rst Throwing "x86" on the name doesn't change my objections, this is still an SNP/TDX specific doc pretending to be more generic then it actually is. I don't understand the resistance to picking a name that makes it abundantly clear the doc covers a very specific niche of confidential computing.
