On Tue, Mar 21, 2023 at 04:05:35PM -0400, James Bottomley wrote: > 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). We did not consider to work on the x86-64 crate for now, that would open a new can of worms and would have delayed the project even further. I agree that the crate would benefit from that, but targeting questions like how to introduce new functionality while keeping it compatible to other users is a project on its own. COCONUT is now in a state where it has its own page-table and IDT/entry code implementations which fit its needs and can be quickly adapted as we move forward. When the dust settles we can re-visit that question and start contributing back to this crate and possibly adopt it. There is actually one thing from the crate I would like to have in COCONUT too, which is the abstraction for VirtAddr and PhysAddr. COCONUT just defines those as usize, which is rather limited and leads to ugly code here and there. > That's entirely possible, so what are the chances of combining the > projects now so we don't get a split in community effort? That is not on us to decide. I agree that a single effort is much better, but at the same time I don't think that porting upstream code between both implementations is worthwile (things are different with the work that is currently happening on-top of linux-svsm). >From a functionality pov both projects are mostly on par in their upstream branches. COCONUT is lacking one piece or another, like it does not work around the VMSA@2M-aligned erratum yet. On the other hand COCONUT has a bigger code-base, implementing exception fixups and bracktraces already. Soon COCONUT will gain an ELF parser (and building on that ASLR) to load the SVSM kernel as an ELF file from the stage2 loader. The ELF parser is needed anyway for ring-3 support, other changes are also under development. There is of course work building on linux-svsm out there, too. It would be interesting to get an overview of that. We are already looking into porting over the attestation code IBM wrote for linux-svsm (although we would prefer IBM submitting it :) ). The vTPM code out there can not be ported over as-is, as COCONUT will not link a whole TPM library in its code-base. But maybe it can be the base for a separate vTPM binary run by COCONUT. In general, since both projects are written in Rust and the APIs are small, it is not a big effort to port over changes for linux-svsm to COCONUT. 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
