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

[Nicolai Stange <nstange@suse.de>]

Hi Tyler,

Tyler Fanelli <tfanelli@redhat.com> writes:

> On 4/29/25 6:46 PM, Nicolai Stange wrote:
>> Hi Stefano,
>> Stefano Garzarella <sgarzare@redhat.com> writes:
>> 
>>> On Wed, 16 Apr 2025 at 16:08, Nicolai Stange <nstange@suse.de> 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 :)
>> 
>
> 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).

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)