On Thu, May 04, 2023 at 01:04:09PM -0400, James Bottomley wrote: > 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. It all depends on what the SVSM allows ring-3 to do, or in other words, how the security model is implemented which locks down the ring-3 services. For example, I can see an attestation service implemented in ring-3 as the exclusive owner of the VMPCK0 key (enforced by SVSM ring-0 code). > 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. The security model is certainly not fully designed in all details, but when comparing an all-ring-0 (with everything in one address space) approach to a split-code model which moves functionality into separate address spaces and less privileged execution contexts, my bet is that the latter will always win. This is something we know already, so there is no need to re-learn that by evolution. > 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). That, in contrast, is something I would leave to evolution. We can build the services (attestation, TPM, ...) and see if they benefit from a shared-lib for crypto. The dynamic linking for that is certainly not trivial, but can also be fully done in ring-3. > 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. Another reason to move all of this to ring-3. Ring-3 services can be written in C and use C libraries as needed without lowering the security of the ring-0 rust code. Regards, -- Jörg Rödel jroedel@xxxxxxx SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
