[svsm-devel] [RFC] moving libstpm bindings and safe abstractions into a separate repository

[Claudio Siqueira de Carvalho]

On Fri, 2024-04-19 at 09:50 +0200, Carlos López wrote:
> 
> On 19/4/24 9:38, Carlos López wrote:
> > > > Currently we do have a separate crate for the raw bindings in our
> > > > ever-growing monorepo, but the safe abstractions are in the SVSM kernel
> > > > crate.
> > > > 
> > > > This change would improve the reusability of the safe abstractions for
> > > > other projects, and also make it easier for third parties to find our
> > > > implementation.
> > > 
> > > You may want to have a look at the kernel/src/vtpm/mstpm/wrapper.rs as 
> > > it would
> > > require some svsm/kernel functions to be visible to the libmstpm-sys.
> > 
> > To be honest I'm not sure why those wrappers are implemented in terms of
> > of these mem_allocate(), mem_reallocate(), etc. functions. As far as I
> > can tell we can simply use the functions in the alloc crate that call
> > into the global allocator (alloc::alloc::alloc(), realloc(), etc.). The
> > downstream user would just need to have a global allocator.
> Just realized the use of the layout functions.


>  I guess we could declare
> the needed functions (malloc, free, etc.) as extern and have downstream
> users implement them? Not sure if that would work.
> 

I think that should work. We could keep the wrapper.rs in the SVSM kernel or
create a new workspace member/repository for it. Maybe the latter is better, I
remember that the solution I found to prevent it from being compiled in for test
and doc-test may not be ideal.

Best,
Claudio

> -- 
> Carlos López
> Security Engineer
> SUSE Software Solutions