On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote: > Could you describe these incompatible goals and explain why you think > they are incompatible (as in why you and AMD don't think you can agree > on it)? That would help the rest of us understand where the two SVSM > implementations fit in our ongoing plans. The goal of COCONUT is to have an SVSM which has isolation capabilities within itself. It already has percpu page-tables and in the end it will be able to run services (like the TPM) as separate processes in ring 3 using cooperative multitasking. With the current linux-svsm code-base this is difficult to achieve due to its reliance on the x86-64 crate. For supporting a user-space like execution mode the crate has too many limitations, mainly in its page-table and IDT implementations. The IDT code from that crate, which is also used in linux-svsm, relies on compiler-generated entry-code. This is not enough to support a ring-3 execution mode with syscalls and several (possibly nested) IST vectors. The next problem with the IDT code is that it doesn't allow modification of return register state. This makes it impossible to implement exception fixups to guard RMPADJUST instructions and VMPL1 memory accesses in general. When we looked at the crate, the page-table implementation supported basically a direct and an offset mapping, which will get us into problems when support for non-contiguous mappings or sharing parts of a page-table with another page-table is needed. So in the very beginning of the project I decided to go with my own page-table implementation. Of course we could start changing linux-svsm to support the same goals, but I think the end result will not be very different from what COCONUT looks now. 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
