On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@xxxxxxx> wrote: > > Hi Tom, > > thanks for that comparision! > > On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > > While both SVSM implementations use the Qemu Firmware Configuration > > (fw_cfg) interface, the coconut-svsm relies on it a bit more than > > linux-svsm. In either case, other interfaces may need to be supported in > > order for an SVSM to work with a VMM other than Qemu. > > Right, that is something I have been thinking about. After I talked to a > few others about it, I came to the conclusion that neither COCONUT nor > linux-svsm use an optimal interface to request information from the HV. > I think it would be best if we move to a model where the MADT and E820 > tables from QEMU (or any other HV) are part of the measured initial > memory image, to make that data trusted. But we can discuss that > separately. > > > - Both SVSMs end up located in a memory slot outside of memory that is > > reported to the guest. Coconut-svsm gets the location and size from > > fwcfg, which is customizable via the Qemu command line. Linux-svsm gets > > the location and size from the build process and validates that location > > and size. > > Correct, COCONUT also has a fall-back where it just uses the last 16MB > of guest RAM if the fw_cfg file is not there. That needs OVMF support, > though. > > > - Pagetables: > > Page table support can be tricky with the x86_64 crate. But in general > > I believe it could still be used. Coconut-svsm uses a dynamic offset- > > based approach for pagetables based on the final physical address > > location. This offset could be utilized in the x86_64 crate > > implementation. When CPL3 support comes around, that would require > > further investigation. > > Yeah, COCONUT does not only use an offset mapping, it also has specific > mappings for the per-cpu areas. Those are mapped at a fixed location, > same with stacks, so the needs already go beyond an offset mapping. > > > - Coconut-svsm copies the original Secrets Page and the "frees" the memory > > for it. I couldn't tell if the memory is zeroed out or not, but > > something that should be looked at to ensure the VMPCK0 key is not > > leaked. > > Thanks, that is a real issue. I just wrote a fix for that. > > > Some questions for coconut-svsm: > > - Are there any concerns with using existing code/projects as submodules > > within coconut-svsm (e.g. OpenSSL or a software TPM implementation)? > > One of our design goals for linux-svsm was desirability to easily > > allow downstream users or products to, e.g., use their own crypto > > (e.g. company preferred) > > No concerns from my side to run any code you want in a CPL-3 module. > This includes code which uses external libraries such as openssl or > libtpm. The modules will be in an archive file packaged with the SVSM > binary, so that everything that runs is measured at launch time. > > > - Are you open to having maintainers outside of SUSE? There is some > > linux-svsm community concern about project governance and project > > priorities and release schedules. This wouldn't have to be AMD even, > > but we'd volunteer to help here if desired, but we'd like to foster a > > true community model for governance regardless. We'd love to hear > > thoughts on this from coconut-svsm folks. > > Yes, I am definitely willing to make the project more open and move to a > maintainer-group model, no intention from my side to become a BDFL for > the project. I just have no clear picture yet how the model should look > like and how to get there. I will send a separate email to kick-start a > discussion about that. > > > - 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. > > 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. > > 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 > > 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. > > > Since we don't want to split resources or have competing projects, we are > > leaning towards moving our development resources over to the coconut-svsm > > project. > Not to throw a wrench in the works, but is it possible for us to have an RTMR protocol as a stop-gap between a fully paravirtualized vTPM and a fully internalized vTPM? The EFI protocol CC_MEASUREMENT_PROTOCOL is already standardized, and it can serve as a hardware-rooted integrity measure for a paravirtualized vTPM. This solution would further allow a TDX measured boot solution to be more thoroughly supported earlier, given that we'd need to have the RTMR event log replay logic implemented. > Great move, much appreciated, thanks a lot for that! Let's work together > to make that happen. > > 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 > -- -Dionna Glaze, PhD (she/her)
