mbed-tls May 2020

mbed-tls@lists.trustedfirmware.org

7 participants
13 discussions

Re: [mbed-tls] Fwd: MBEDTLS never exits ecp_double_jac function call

by Gilles Peskine

Hi Sirjee, Does this fail systematically or randomly? Can you reproduce this with a very small program that only opens a TLS connection and nothing else, like programs/ssl/ssl_client1? At a guess, but this is only a guess, maybe this is the part of your program which uses the largest amount of stack, and there's a stack overflow that causes some variable to be overwritten. Please try increasing the stack size. -- Gilles Peskine Mbed TLS developer P.S. The config.h attachment didn't come through, but a graphical signature did. Please check your email settings when posting to the list. On 04/05/2020 10:50, Sirjee Rooplall via mbed-tls wrote: > > > Hi Support, > > I am using MBEDTLS and most of it works, except I have hit a snag > where I am trying to communicate to an https server, and it fails in > the ssl->handshake-step (ssl_write_client_key_exchange). > > My stack trace shows that it gets to the function ecp_double_jac and > never exits. It is looping at > MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); > MOD_ADD( T );. > Stack trace: > test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, > const mbedtls_mpi * B) Line: 1287 > test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 > test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, > size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 > test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * > R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx > * rs_ctx) Line: 2095 > test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point > * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 > test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) > Line: 84 > test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng) Line: 102 > test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * > ctx, size_t * olen, int point_format, unsigned char * buf, size_t > blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > int restart_enabled) Line: 514 > test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, > size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng) Line: 542 > test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) > Line: 3362 > test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * > ssl) Line: 4015 > test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) > Line: 9564 > test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 > test.elf! https_do_tls_handshake (struct httpsConfigStr * client) > Line: 419 > test.elf! HttpsStateMachine Line: 366 > test.elf! HttpsTask (void * param) Line: 110 > test.elf! ?? Line: 110 > > MBEDTLS VERSION: mbed TLS 2.18.0 > PLATFORM: embedded microchip SAME70 micro controller. > > I have attached my config.h file. > > What am I doing wrong? > >

4 years, 6 months

Fwd: MBEDTLS never exits ecp_double_jac function call

by Sirjee Rooplall

Hi Support, I am using MBEDTLS and most of it works, except I have hit a snag where I am trying to communicate to an https server, and it fails in the ssl->handshake-step (ssl_write_client_key_exchange). My stack trace shows that it gets to the function ecp_double_jac and never exits. It is looping at MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); MOD_ADD( T );. Stack trace: test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, const mbedtls_mpi * B) Line: 1287 test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2095 test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 84 test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 102 test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * ctx, size_t * olen, int point_format, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, int restart_enabled) Line: 514 test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 542 test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) Line: 3362 test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * ssl) Line: 4015 test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) Line: 9564 test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 test.elf! https_do_tls_handshake (struct httpsConfigStr * client) Line: 419 test.elf! HttpsStateMachine Line: 366 test.elf! HttpsTask (void * param) Line: 110 test.elf! ?? Line: 110 MBEDTLS VERSION: mbed TLS 2.18.0 PLATFORM: embedded microchip SAME70 micro controller. I have attached my config.h file. What am I doing wrong?

4 years, 6 months

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Simon Butcher

Hi All, I appreciate I'm coming very late to this discussion, but I want to make a point and suggestion. The performance of the asymmetric functions is less than ideal, and whilst I think we can all agree that the ECC code should be rewritten at some point to be more competitive, one of the issues with the performance is that the MPI code uses malloc() a lot. There are competing crypto libraries out there that are faster and use a smaller RAM footprint and don't use dynamic memory allocation at all. Our memory allocation code is also kind of slow, and has a primitive and simplistic design of a linked list. These are very similar points to those Manuel was making to remove the feature in the first place - however - short of investing the time in rewriting the asymmetric functions, what we could do as a quick fix is to replace the existing memory code with a block allocation scheme - which should be much faster, speed up the asymmetric functions (in theory), avoid fragmentation, be more deterministic, and a better fit for embedded applications. That could then become the basis of the library for other projects too. I wouldn't mind contributing such a feature, as I had to write something very similar last week anyway. If I do it - will you accept it? Kind regards Simon On 09/04/2020, 12:07, "mbed-tls on behalf of Dan Handley via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got. Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them! I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available. I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts. Regards Dan. > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Ronald Cron via mbed-tls > Sent: 09 April 2020 08:47 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, I think this is related to the more general need for an implementation of > the C standard library for trusted firmware projects. As far as I know TF-A > and TF-M don't use the standard library provided by compilation toolchains. > The rationale is to have complete control over the trusted firmware code. > Currently they both have their own partial implementation of the parts of the > C standard library they need. > > This memory_buffer_alloc.c module in question here is another partial > implementation of the C standard library. Currently TF-A and TF-M don't > use/provide dynamic memory allocations but PSA-FF explicitly mentions that an > SPM implementation may support dynamic memory allocation. Thus it is possible > that TF-M at some point consider providing dynamic memory allocation support. > > All of this to say that a possible way forward may be to remove > memory_buffer_alloc.c from the code base when there is a C standard library > implementation common to trustedfirmware.org projects (is there already a > security oriented open source implementation out there ?). > > In Mbed TLS, it would also make sense to me to, by default, not use C > standard libraries provided by compilation toolchains > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > Thanks, Ronald. > > > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Manuel Pegourie-Gonnard via mbed-tls > Sent: 08 April 2020 12:42 > To: mbed-tls(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove memory_buffer_alloc.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > Currently the crypto library includes a module called memory_buffer_alloc.c, > disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), > which provides implementations of calloc() and free() based on a user- > provided buffer (which could be static or on the stack), suitable for use in > the rest of the crypto, X.509 and TLS libraries as replacements to the > standard functions. > > In addition to providing replacement calloc() and free(), the module also > offers some facilities for measurement and debugging. > > We're considering dropping this module and removing it from the code base > entirely for the following reasons: > > - Memory allocators are not our core area of expertise. > > - This allocator is pretty basic and has a large allocation overhead. For > example for ECC computations, the overhead can be as large as the actual > memory used. > > - Using this allocator also tends to slow things down, so we don't run many > tests with it enabled. > > - In the future when we split between PSA Crypto on one side and Mbed TLS and > X.509 on the other, it's unclear on which side this allocator should fall. > Which can be taken as a sign that it doesn't really belong here. > > On the other hand, we're hesitating for the following reasons: > > - We know from bug reports and questions that some people are using it. > > - Unlike other modules we'd like to drop, there isn't a strong security > incentive to dropping this allocator, it's merely a matter of how we spend > our maintenance resources. > > What do you think? Should we keep maintaining this allocator as part of Mbed > TLS? Should we drop it and focus on our core instead? If you're using this > allocator, why did you pick it over other alternatives? > > Regards, > Manuel. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 6 months

2024

2023

2022

2021

2020

mbed-tls May 2020