Hi Carlos, On 6/14/23 06:55, Carlos Bilbao wrote: > Hello Randy, > > On 6/12/23 17:43, Randy Dunlap wrote: >> Hi-- >> >> On 6/12/23 09:47, Carlos Bilbao wrote: >>> Kernel developers working on confidential computing for virtualized >>> environments in x86 operate under a set of assumptions regarding the Linux >>> kernel threat model that differs from the traditional view. Historically, >>> the Linux threat model acknowledges attackers residing in userspace, as >>> well as a limited set of external attackers that are able to interact with >>> the kernel through networking or limited HW-specific exposed interfaces >>> (e.g. USB, thunderbolt). The goal of this document is to explain additional >>> attack vectors that arise in the virtualized confidential computing space >>> and discuss the proposed protection mechanisms for the Linux kernel. >>> >>> Reviewed-by: Larry Dewey <larry.dewey@xxxxxxx> >>> Reviewed-by: David Kaplan <david.kaplan@xxxxxxx> >>> Co-developed-by: Elena Reshetova <elena.reshetova@xxxxxxxxx> >>> Signed-off-by: Elena Reshetova <elena.reshetova@xxxxxxxxx> >>> Signed-off-by: Carlos Bilbao <carlos.bilbao@xxxxxxx> >>> --- >>> >>> --- >>> Documentation/security/index.rst | 1 + >>> .../security/x86-confidential-computing.rst | 298 ++++++++++++++++++ >>> MAINTAINERS | 6 + >>> 3 files changed, 305 insertions(+) >>> create mode 100644 Documentation/security/x86-confidential-computing.rst >>> >>> diff --git a/Documentation/security/x86-confidential-computing.rst b/Documentation/security/x86-confidential-computing.rst >>> new file mode 100644 >>> index 000000000000..5c52b8888089 >>> --- /dev/null >>> +++ b/Documentation/security/x86-confidential-computing.rst >>> @@ -0,0 +1,298 @@ >>> +====================================================== >>> +Confidential Computing in Linux for x86 virtualization >>> +====================================================== >>> + >>> +.. contents:: :local: >>> + >>> +By: Elena Reshetova <elena.reshetova@xxxxxxxxx> and Carlos Bilbao <carlos.bilbao@xxxxxxx> >>> + >>> +The basic CoCo guest layout includes the host, guest, the interfaces that >>> +communicate guest and host, a platform capable of supporting CoCo VMs, and >>> +a trusted intermediary between the guest VM and the underlying platform >>> +that acts as a security manager. The host-side virtual machine monitor >>> +(VMM) typically consists of a subset of traditional VMM features and >>> +is still in charge of the guest lifecycle, i.e. create or destroy a CoCo >>> +VM, manage its access to system resources, etc. However, since it >>> +typically stays out of CoCo VM TCB, its access is limited to preserve the >> >> to preserving the >> ? > > I think that using "preserving" and "preserve" here may result in two > different interpretations: > > "limited to preserve the security objectives" suggests that the limited > access is enforced to preserve the security guarantees. In other words, the > act of limiting access itself, particularly from the VMM, helps to maintain > the security objectives. This is what we want to say. > > "limited to preserving the security objectives" suggests that the access of > the VMM is limited to the components that allow the VMM to preserve the > security objectives. > > Hope that makes sense? Yes, I get it, thanks. >> >>> +security objectives. >>> + >>> +In the following diagram, the "<--->" lines represent bi-directional >>> +communication channels or interfaces between the CoCo security manager and >>> +the rest of the components (data flow for guest, host, hardware) :: >>> + >>> + +-------------------+ +-----------------------+ >>> + | CoCo guest VM |<---->| | >>> + +-------------------+ | | >>> + | Interfaces | | CoCo security manager | >>> + +-------------------+ | | >>> + | Host VMM |<---->| | >>> + +-------------------+ | | >>> + | | >>> + +--------------------+ | | >>> + | CoCo platform |<--->| | >>> + +--------------------+ +-----------------------+ >>> + >>> +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. >>> + >>> +Confidential Computing threat model and its security objectives >>> +=============================================================== >>> + >>> +Confidential Computing adds a new type of attacker to the above list: a >>> +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 >> >> Hyphens (dashes) are not normally used for a parenthetical phrase AFAIK. > > Yes, parentheses would be more appropriate. > >> >>> +kernel communication with most of the HW:: >> >> I would prefer to capitalize "kernel" above. > > I'm not sure I follow, we don't capitalize kernel elsewhere, why here? > My mistake in reading. :( Thanks. -- ~Randy
