Hi Mark,

This error with r7 is becuase the cortex-m uses it when building with debug. To get around this you can add

-fomit-frame-pointer

to your CFLAGS.

I added a note in the STM32Cube pack README.md regarding this:
https://github.com/wolfSSL/wolfssl/tree … pack-usage

If seeing `error: r7 cannot be used in 'asm'` add `-fomit-frame-pointer` to the CFLAGS. This only happens in debug builds, because r7 is used for debug.

Thanks,
David Garske, wolfSSL

Hi Riker,

The error -229 means the RSA signature verification failed. It could mean the public key presented doesn't match the private key used. It could also be that it's an RSA key size that is not enabled. For example using RSA 4096-bit might require setting SP_INT_BITS 4096. Or perhaps it's trying to use an older SHA-1 or a new SHA2/SHA3 that is not enabled.

Can you share more of the logs or wirehshark? Can you tell us more about the hardware platform running wolfSSH client? Can you share the build settings used for wolfCrypt and wolfSSH?

Thanks,
David Garske, wolfSSL

Hi Rickou,

That's odd. Is it the same version of the CubeMX HAL for AES? Are you using the same AES GHASH build options, example: GCM_SMALL or GCM_TABLE_4BIT? The actual AES GCM test happens later. If it also fails then you might check to make sure the clock for the AES peripheral is enabled (__HAL_RCC_AES_CLK_ENABLE();).

Thanks,
David Garske, wolfSSL

Hi Rickou,

This issue was fixed in PR https://github.com/wolfSSL/wolfssl/pull/7787 on July 29, 2024.

Please confirm you are using the latest master or patch your code with this PR.

If you continue to have any issues please let us know.

Thanks,
David Garske, wolfSSL

The memory use is lower for Single Precision (SP) math implementations, which is why using WOLFSSL_HAVE_SP_RSA resolves it for you. It also defaults to using math variables from stack, unless WOLFSSL_SMALL_STACK is used (then it comes from heap.

Thanks, David Garske, wolfSSL

Hi Daniel,

Your use case sounds very interesting and is one we do support. The handshake operations taking the most time are the cryptographic ones for asymmetric operations like shared secret and sign/verify. If you are using an ECC only cipher suite like ECDHE-ECDSA then you can enable our non-blocking crypto with TLS and break operations into much smaller chunks.

When the non-blocking build option is enabled the crypto calls will return WC_PENDING_E and you would just call the wolfSSL_connect/wolfSSL_accept API's again until complete.

This does require our asynchronous code from https://github.com/wolfssl/wolfAsyncCrypt.

We posted a nice blog on it here: https://www.wolfssl.com/wolfssl-bare-me … yptography

This use case is supported and used by many customers. However it might be useful to setup a call to walk you through it and hear about your use case. We will be emailing you directly to reach out.

Thanks,
David Garske, wolfSSL

Hi Eduardo,

I am not aware of any issues generating the configuration files. Can you confirm you have both wolfSSL and wolfTPM cube packs installed and selected/enabled?

https://www.wolfssl.com/files/ide/I-CUBE-wolfTPM.pack
https://www.wolfssl.com/files/ide/I-CUBE-wolfSSL.pack

Both packs should generate their own conf files using these templates:
https://github.com/wolfSSL/wolfTPM/blob … t_conf.ftl
https://github.com/wolfSSL/wolfssl/blob … t_conf.ftl

Can you tell me more about your project and use-case? I can't attach files here, but you can send an email to support at wolfssl dot com to use our ZenDesk system to get support. I can send you examples of the generated files.

Thanks,
David Garske, wolfSSL

Hi Eduardo,

Thanks for your interest in using our STM32 Cube pack for wolfTPM. I assume you generated the IAR project using the CubeMX tool? The tool is supposed to add a pre-processor macro `USE_HAL_DRIVER` to your project. If not please add it. Then it will use the generated configuration file `wolfSSL.I-CUBE-wolfTPM_conf.h`.

For reference wolfssl/options.h is a file generated from ./configure or CMake, which you are not using.

Can you tell us more about your project?

Thanks,
David Garske, wolfSSL

Hi Arto,

Thank you for your interest in wolfBoot on the STM32. Which STM32 part are you trying to evaluate for?

We have automated testing that builds and runs most of the supported targets, so I am surprised you had issues. I will specifically try and reproduce the STM32G0 and STM32F4 issues.

We provide example configurations in config/examples that are good starting points, but typically you need some customizing for your specific part. The test-apps are really just for testing to demonstrate and can be useful for showing how to adjust your application to support the signed image header.

We will also reach out directly as we'd like to here about your project and how we can support you.

Thanks,
David Garske, wolfSSL

Hi Thomas,

Correct. The buckets and number of buckets can be overridden at build-time. See https://github.com/wolfSSL/wolfssl/blob … mory.h#L99

The buckets `WOLFMEM_BUCKETS` and number of buckets `WOLFMEM_MAX_BUCKETS` can all be setup for your specific implementation.

I don't have a good template for the buckets with RSA. I would recommend logging the mallocs() using `WOLFSSL_DEBUG_MEMORY` to see what your heap profile looks like. Then setup buckets of appropriate size. The buckets are buffer pools are various sizes. If the next available size is not available it will select the next largest.

Thanks,
David Garske, wolfSSL

Hi MO380,

Was your LWIP already working previously? That appears to be an internal LWIP issue. Have you properly configured LWIP NATIVE?

Have you tried without WOLFSSL_LWIP_NATIVE defined, which uses the LWIP POSIX interfaces (connect/send/recv/close).

Thanks,
David Garske, wolfSSL

Hi Patrick,

Yes that is a known issue and already fixed. You would need to update your wolfSSL. The latest is v5.6.6. You might be able to just pull over sp_cortexm.c if you are opposed to a full update.

Thanks,
David Garske, wolfSSL