On Tue, 2023-03-21 at 16:14 +0100, Jörg Rödel wrote: > 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. OK, so this doesn't sound like a problem with the AMD svsm, it sounds like a (solvable) issue with a particular crate in embedded rust. I have to say that embedded rust is so new, it's really hard to tell if this is just because it was developed by someone who didn't think of all the OS implications or because it's a fundamental issue within the rust ecosystem. Have you tried improving this crate? ... and also it's a nuisance we came to with our insistence on using rust; it certainly wouldn't have been an issue in C. I suspect improving the crate would help everyone (although I note the linux kernel isn't yet using this crate either). > 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. That's entirely possible, so what are the chances of combining the projects now so we don't get a split in community effort? James
