1 Reply by marco

(3 replies, posted in wolfSSL)

Hi,

Thank you for your reply. Please refer to the codebase used in this Pull Request for guidance: https://github.com/wolfSSL/wolfssl/pull/6475 (which includes some compile fixes for the reported options).

I ran a quick test with the following configuration options:


./configure --disable-all --enable-tls13 --enable-dtls13 --enable-dtls --enable-psk --disable-dh --disable-ecc --disable-rsa --enable-sp-asm --disable-sha384 --disable-sha512 --disable-sha --disable-sha224 --disable-md5 CFLAGS="-DWOLFSSL_STATIC_PSK -DMAX_PSK_ID_LEN=32 -DWOLFSSL_MAX_MTU=300"

Our memory tool indicates a peak memory usage of around 8-9 KB per connection. The settings above assume the usage of PSK with PSK_KE exchange mode, using the TLS_AES_128_GCM_SHA_256 ciphersuite, and a maximum MTU of ~300 bytes. However, please note that this is a raw number that may vary depending on your application profile and hardware target. I'm confident that if you're not using public key authentication, this number can be further reduced by tailoring it to your application profile.

Using static memory (with `--enable-staticmemory`) unfortunately increases the memory usage due to the fragmentation of a more simple allocator. However, if static memory is mandatory, the impact of fragmentation can be reduced by choosing a bucket allocation size that works better for your application. Please refer to `wolfSSL_StaticBufferSz` for further details.

If you have any additional questions, please feel free to ask.
Regards,
Marco

Go to forum: wolfSSL

2 Reply by marco

(3 replies, posted in wolfSSL)

Hi!

Are you primarily focused on minimizing code size, or is your main goal to reduce run-time memory usage per connection? In both case, what's the maximum amount of memory you can use?

Also, is there any particular reason to use wc_LoadStaticMemory? Is it possible for your target to utilize dynamic memory allocation through a malloc-like allocator?

Best regards,
Marco

Go to forum: wolfSSL

3 Reply by marco

(2 replies, posted in wolfSSL)

Hi _angelo_,

1) About TLS 1.3, is it possible to configure wolfssl to disable change_cipher_spec records ?

Sending of change_chiper_spec should be disabled by default and enabled by the preprocessor define WOLFSSL_TLS13_MIDDLEBOX_COMPAT at compile time. If you aren't using this define and you still see sending of change_cipher_spec, feel free to provide more details on your compilation configuration and I'll look at it.

2) Is it possible co configure the record data chunk size ?

Client may negotiate a maximum message size with the server using the max_fragment_length extension. Other than that wolfSSL have no other way of automatically limiting the max size of a message but it can also be done at the application layer. What's your use case?

- Marco

Go to forum: wolfSSL

4 Reply by marco

(1 replies, posted in wolfBoot)

Hi Thisora,

Thanks for your interest in wolfBoot.
Regarding the use of the linker to build the final image:

I think it's best to separate as much as possible the linking of the application, other stages of the bootloader, and wolfboot itself.
This allows better flexibility and abstractions among these different components, so I believe concatenating the components (as we do with the binassembly tool) is the most simple and effective approach.
If you really want to use the linker for this purpose you can always do that externally, without coupling these components in the normal wolfboot building process.
Do you see other strong reasons to not use concatenate the files directly with binassembly?

Besides that, please note that if you want to file a PR it shouldn't alter other targets and it should include tests.

Thanks
Marco

Go to forum: wolfBoot