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

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

[Nicolai Stange]

Hi all,

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.

Thanks!

Nicolai

[1] https://github.com/nicstange/cocoon-tpm
[2] https://github.com/coconut-svsm/svsm/pull/528
[3] https://github.com/nicstange/cocoon-tpm-crypto-ec-key-gen-demo

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

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

[Stefano Garzarella]

Hi Nicolai,
CCing Tyler

On Wed, 16 Apr 2025 at 16:08, Nicolai Stange <nstange@suse.de> wrote:
>
> Hi all,
>
> 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.

Thanks,
Stefano

>
> Thanks!
>
> Nicolai
>
> [1] https://github.com/nicstange/cocoon-tpm
> [2] https://github.com/coconut-svsm/svsm/pull/528
> [3] https://github.com/nicstange/cocoon-tpm-crypto-ec-key-gen-demo
>
> --
> SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich
> (HRB 36809, AG Nürnberg)
>

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

[Nicolai Stange]

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,

Nicolai

[4] https://github.com/nicstange/svsm/tree/cocoon-tpm-crypto-integration-poc

>>
>> [1] https://github.com/nicstange/cocoon-tpm
>> [2] https://github.com/coconut-svsm/svsm/pull/528
>> [3] https://github.com/nicstange/cocoon-tpm-crypto-ec-key-gen-demo
>>

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

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

[Tyler Fanelli]

Hi Nicolai,

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?


Tyler

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

[Nicolai Stange]

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)

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

[Stefano Garzarella]

On Wed, 30 Apr 2025 at 07:20, Nicolai Stange <nstange@suse.de> wrote:
>
> 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 :)

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