[svsm-devel] Using crates in SVSM kernel

[Stefano Garzarella]

Hi John,

On Mon, 7 Apr 2025 at 21:47, John Allen <john.allen at amd.com> wrote:
>
> Hi all,
>
> I am new to the project and embedded rust in general. I'm working with
> Pankaj G. on SVSM support for SNP live migration and I'm starting to
> sketch out some code for key exchange, but I'm learning that many crates
> available in non-embedded rust depend on std or on OS abstractions. For
> example, I want to generate a ecdsa p384 key using the p384 crate, but
> this depends on "get_random" which relies on a whitelist of supported
> targets to determine the rng method. This is just one of several crates
> that I would have liked to use, but depend on std or are incompatible
> with the "x86_64-unknown-none" target.

Yep, the dependency must support a way (usually a feature) to enable
`no_std` support.

What I have seen so far is that crates usually support 2 features (or
just one of them used to discriminate): `std` and `alloc`. `std` is
enabled by default and `alloc` must be enabled to support no_std,
disabling the default features.

>
> What is best practice when it comes to including libraries like this?
> What options do we have here other than reimplementing functionality
> from these crates or is reimplementation the expected course of action
> in this environment?

The option is to find crates that support no_std. You can see some of
them (aes-gcm, zerocopy) in kernel/Cargo.toml

I suggest you to take a look at
https://github.com/coconut-svsm/svsm/pull/528 where we added several
dependencies that supports no_std like the p384 crate that you
mentioned and the rdrand crate for the rng method:
https://github.com/coconut-svsm/svsm/pull/528/files#diff-45b9953e854edc633b513d9ce5dbb79628995bd5fc7f8880372d76bb4fffa0fd

Thanks,
Stefano