On 2023-05-04 at 13:04 -04, James Bottomley <jejb@xxxxxxxxxxxxx> wrote... > On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: >> On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > [...] >> > - On the subject of priorities, the number one priority for the >> > linux-svsm project has been to quickly achieve production >> > quality vTPM support. The support for this is being actively worked >> > on by linux-svsm contributors and we'd want to find fastest path >> > towards getting that redirected into coconut-svsm (possibly >> > starting with CPL0 >> > implementation until CPL3 support is available) and the project >> > hardened for a release. I imagine there will be some competing >> > priorities from coconut-svsm project currently, so wanted to >> > get this out on the table from the beginning. >> >> That has been under discussion for some time, and honestly I think >> the approach taken is the main difference between linux-svsm and >> COCONUT. My position here is, and that comes with a big 'BUT', that I >> am not fundamentally opposed to having a temporary solution for the >> TPM until CPL-3 support is at a point where it can run a TPM module. > > OK, so this, for IBM, is directly necessary. We have the vTPM pull > request about ready to go and we'll probably send it still to the AMD > SVSM. Given that the AMD SVSM already has the openssl library and the > attestation report support, do you want to pull them into coconut > directly so we can base a coconut vTPM pull request on that? > >> And here come the 'BUT': Since the goal of having one project is to >> bundle community efforts, I think that the joint efforts are better >> targeted at getting CPL-3 support to a point where it can run >> modules. On that side some input and help is needed, especially to >> define the syscall interface so that it suits the needs of a TPM >> implementation. > > Crypto support in ring-0 is unavoidable if we want to retain control of > the VMPCK0 key in ring-0. I can't see us giving it to ring-3 because > that would give up control of the SVSM identity and basically make the > ring-0 separation useless because you can compromise ring-3 and get the > key and then communicate with the PSP as the SVSM. I'm a but confused regarding the roles that VMPL vs rings is in the security model here. In particular, I assume that any attack on ring3 would still have to cross either the VMPL boundary (if coming from the guest) or the TEE boundary (if coming from the host). > > I think the above problem also indicates no-one really has a fully > thought out security model that shows practically how ring-3 improves > the security posture. So I really think starting in ring-0 and then > moving pieces to ring-3 and discussing whether this materially improves > the security posture based on the code and how it operates gets us > around the lack of understanding of the security model because we > proceed by evolution. And there is definitely a lot of complexity added by supporting ring3. You are essentially getting the complexity of a "real" operating system. By contrast, TDX is providing the same kind of isolation with secure enclaves, but at least the base OS kernel is shared. The expected benefit is to be able to run more complex code from ring3 with a better way to handle malfunctions, faults, whatever. At least that's the way I read it. So it's a way to write software in a more modular way. IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so presumably, not accesible from host or guest. If we consider this property as strong, then do we really care entrusting ring3 with sensitive data? > > The next question that's going to arise is *where* the crypto libraries > should reside. Given they're somewhat large, duplicating them for > every cpl-3 application plus cpl-3 seems wasteful, so some type of vdso > model sounds better (and might work instead of a syscall interfaces for > cpl-0 services that are pure code). I don't understand what you call "pure code". I presume you mean "code that does not need to access ring0 data"? > >> It is also not the case that CPL-3 support is out more than a year or >> so. The RamFS is almost ready, as is the archive file inclusion[1]. >> We will move to task management next, the goal is still to have basic >> support ready in 2H2023. >> >> [1] https://github.com/coconut-svsm/svsm/pull/27 > > Well, depending on how you order them, possibly. The vTPM has a simple > request/response model, so it really doesn't have much need of a > scheduler for instance. And we could obviously bring up cpl-3 before a > module loader/ram filesystem and move to that later. > >> If there is still a strong desire to have COCONUT with a TPM (running >> at CPL-0) before CPL-3 support is usable, then I can live with >> including code for that as a temporary solution. But linking huge >> amounts of C code (like openssl or a tpm lib) into the SVSM rust >> binary kind of contradicts the goals which made us using Rust for >> project in the first place. That is why I only see this as a >> temporary solution. > > I'm not sure it will be. If some cloud or distro wants to shoot for > FIPS compliance of the SVSM, for instance, a requirement will likely be > to use a FIPS certified crypto library ... and they're all currently in > C. That's not to say we shouldn't aim for minimizing the C > dependencies, but I don't see a "pure rust or else" approach > facilitating the initial utility of the project. > > James -- Cheers, Christophe de Dinechin (https://c3d.github.io) Freedom Covenant (https://github.com/c3d/freedom-covenant) Theory of Incomplete Measurements (https://c3d.github.io/TIM)
