Hi James, On Thu, Apr 13, 2023 at 12:57:38PM -0400, James Bottomley wrote: > We (IBM) did look at what it might take to add a vTPM to Coconut, but > we ran into the problem that if we do it at CPL3 (which looks > desirable), then we have to wait until pretty much every one of the > twelve(!) tasks in this list is complete: > > https://github.com/coconut-svsm/svsm/issues/16 Thanks for looking into the code-base. Our approach to getting CPL-3 support is incremental. We can take some shortcuts where possible, as long as the foundations and the underlying design is right, to get code running at CPL-3 at some point in 2H/2023. Looking at the points listed in the issue above, some of them are ready or almost ready (just not included in the main branch yet): * "Archive file in SVSM binary" is implemented * "Page allocator enhancements for reference counting pages" is implemented * "ELF loader" is implemented, there is a pending PR for it. The "RAM file system support" is currently being worked on. All of the listed points probably don't have a 'complete' state, I think we start with something very simple and improve from that later as needed. A primary example is the syscall interface, that will certainly evolve over time as people come along with their own ideas for other modules. The rough plan moving forward is: * Get RAM FS ready * Implement a task and address space abstraction which allows to map RAM FS file contents for CPL-3 * Task switch and sycall entry/exit * Example binary to run for initial tests (that will probably be worked on in parallel) When that is done we can look into how to get a vTPM into a binary and improve the underlying interface as required. Of course progress will be faster with more helping hands :-) There are also a lot of places that don't have a final design yet where help and discussions are beneficial. > At a conservative estimate, it looks like completion of all twelve > would take a team of people over a year to achieve. Some of these > tasks, like task switching and a syscall interface, really don't look > like they belong in a simple service module, like we were imagining an > SVSM would operate, is there some rationale behind this (or ideally > some architecture document that gives the justifications)? I think > what I'm really asking is can we get to CPL3 separation way sooner than > completion of all these tasks? We do not imaging the SVSM to be simple and small, we are imagining it to be secure and extensible. Of course it will always be smaller than a full-blown OS, but the vision is that it can do more than running a vTPM emulation. Also when we start looking into paravisor-like features like ReflectVC-handling later, the SVSM will certainly not be simple anymore. When I talked to people about the SVSM I often heard other interesting ideas what services it can provide. To make this possible and secure the SVSM needs the ability to run multiple modules at CPL-3. And a task concept with a simple FS to load those modules from is, in my opinion, the right approach. Yes, it takes more time than simpler and less flexible approaches, but as one of my favourite TV characters put it: "This is the Way" :-) 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
