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

[Carlos López]

Hi,

On 18/4/24 20:30, Claudio Siqueira de Carvalho wrote:
> On Wed, 2024-04-17 at 12:05 +0200, Carlos López wrote:
>> Hi everyone,
> 
> Hi Carlos,
> 
>>
>> I'd like to suggest that we move both the `libstpm` bindings (currently
>> in `libstpm/`) and safe abstractions (currently in
>> `kernel/src/vtpm/mstpm/`) to a separate repository.
>>
>> This new repository would contain two crates `libstpm-sys` (raw
>> bindings) and `libstpm` (safe abstractions). This follows the official
>> the recommendation in the Cargo Book [0], and mirrors the development of
>> other C-based crates. A few examples, among many:
>>
>> * libgit2-sys and git2 [1]
>> * curl-sys and curl [2]
>> * openssl-sys and openssl [3]
>> * libssh2-sys and ssh2 [4]
> 
> The *-sys recommendations seems to be applicable for packages that link to
> system libraries, which is not the case of the libmstpm.
> 

Not necessarily. Most of those examples embed a git submodule of the
upstream library (just like we do). The user may choose to build the
crate linking against the system library or the embedded copy.

>>
>> 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.

> Are there third parties interested on reusing our libmstpm?

Not that I know of.

> Thanks,
> Claudio
> 
>>
>> I'd like to take opinions from the SVSM community to see if others think
>> it's a positive change or not before starting any work. It's perhaps
>> something that could be discussed in the next SVSM call as well.
>>
>> [0]
>> https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages
>> [1] https://github.com/rust-lang/git2-rs
>> [2] https://github.com/alexcrichton/curl-rust
>> [3] https://github.com/sfackler/rust-openssl
>> [4] https://github.com/alexcrichton/ssh2-rs
>>

Best,
Carlos

-- 
Carlos López
Security Engineer
SUSE Software Solutions