Re: ECC keygen for PR #528 ("Attestation driver and proxy")

On Wed, 30 Apr 2025 at 07:20, Nicolai Stange <[email protected]> wrote:
>
> Hi Tyler,
>
> Tyler Fanelli <[email protected]> writes:
>
> > On 4/29/25 6:46 PM, Nicolai Stange wrote:
> >> Hi Stefano,
> >> Stefano Garzarella <[email protected]> writes:
> >>
> >>> On Wed, 16 Apr 2025 at 16:08, Nicolai Stange <[email protected]> wrote:
> >>>>
> >>>> I managed to carve out and cleanup the first batch ([1]) from my work on
> >>>> an encrypted FS by now. The FS cleanup itself is still WIP, but the
> >>>> crypto parts should be in a usable state.
> >>>>
> >>>> As mentioned on last week's svsm-devel call, it might help with
> >>>> addressing those stack size related issues with ECC keygen in the
> >>>> context of PR #528 ([2]).
> >>>>
> >>>> I prepared some example code for generating an ECC key with NIST P-521,
> >>>> to be found at [3].
> >>>>
> >>>>  From some lax experiments in userspace, peak stack usage is at about 2.3kB.
> >>>> (Which is still way above what I would have expected, given that no
> >>>>   buffers are stored on the stack. I'm currently investigating that).
> >>>>
> >>>> I'm not sure whether merely generating the key is all you need -- FWIW
> >>>> there's also support for ecdh, ecdsa and ecschnorr, in case you're
> >>>> wondering. I'd be happy to come up with some example code for these as
> >>>> well.
> >>>>
> >>>> Please let me know if you have any questions, either here or in today's
> >>>> call.
> >>>
> >>> Cool, thanks for the example code, I guess this can unlock for now
> >>> Tyler's PR and FS support, but as we discussed yesterday in the
> >>> community call, the long term plan is to use OpenSSL/BoringSSL. I'll
> >>> open an issue ASAP to track that work, and I'll start to investigate
> >>> it.
> >> I've implemented a BoringSSL FFI backend as a configurable
> >> alternative
> >> to the cocoon-tpm-crypto now (example code is updated accodingly), and
> >> did a POC integration into SVSM, c.f. [4]. Good news is it still boots :)

This is really cool, thanks for that. I hope you can open a PR soon
and I'll help reviewing it!

> >>
> >
> > Thanks for this. I'm currently updating PR #528 to use
> > cocoon-tpm-crypto for generating ECC keys. For now, should I err
> > towards using the BoringSSL feature?
> >
>
> That would become a Cargo feature ("boringssl") for the svsm kernel
> crate, but yes, we can make it the default, either in the Cargo.toml or
> by specifying it in the Makefile as it's being done for the vtpm IIRC.
>
> One note though: the cocoon-tpm-crypto in its current form depends on a
> 1.86 toolchain, while the svsm fixes 1.82. Either we bump that up, or I
> would have to go figure which of the used language features are
> incompatible with 1.82 and somehow fix that up or work around (one is
> upcasts of &mut dyn's to supertraits).

We already have a PR opened to bump to 1.84, but I think we can go also to 1.86.

Thanks,
Stefano

>
> In either case, as the integration of the boringssl build into the svsm
> environment is non-trival (see that demo POC [4]), I would leave that
> part at least to a separate, dedicated PR.
>
> Thanks!
>
> Nicolai
>
> --
> SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich
> (HRB 36809, AG Nürnberg)
>