These defines are needed when the platform doesn’t have standard functions like `calloc()` and `free()`. (You can find more details on the macros in `config.h`.)
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de>
Date: Wednesday, 17 June 2020 at 13:41
To: "Kaul, Martin" <Martin.Kaul(a)leuze.com>
Cc: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"
Thanks Martin.
It solved my problem! By adding $(CHIBIOS)/os/various/syscalls.c in the makefile and removing following defines, the linker error is gone.
#define MBEDTLS_PLATFORM_C
#define MBEDTLS_PLATFORM_MEMORY
#define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc
#define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree
Now I wonder when these defines are needed? I thought I need to port them to the OS-specific memory allocation. like in freeRTOS, it would be "pvPortCalloc", and for chibios it would be chHeapAlloc. Anybody can give me some hint?
-- Songwei
Gesendet: Mittwoch, 17. Juni 2020 um 12:12 Uhr
Von: "Kaul, Martin" <Martin.Kaul(a)leuze.com>
An: "songwei.fu(a)web.de" <songwei.fu(a)web.de>
Betreff: AW: [mbed-tls] Link error when calling "altcp_tls_create_config_client"
Hi,
_sbrk is need when you using heap memory, for example using malloc() – see following discussion in stackoverflow: https://stackoverflow.com/questions/32446814/undefined-reference-to-sbrk-in…
Maybe that helps.
Best regards
Martin
Von: mbed-tls [mailto:mbed-tls-bounces@lists.trustedfirmware.org] Im Auftrag von songwei fu via mbed-tls
Gesendet: Mittwoch, 17. Juni 2020 11:49
An: mbed-tls(a)lists.trustedfirmware.org
Betreff: [mbed-tls] Link error when calling "altcp_tls_create_config_client"
Hi guys,
I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following:
c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
And these are my settings:
#define MBEDTLS_PLATFORM_C
#define MBEDTLS_PLATFORM_MEMORY
#define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc
#define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree
where chHeapAlloc and chHeapFree are the memory allocation functions from chibios.
(1) Did I miss some settings? or i did something wrong?
(2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs?
Any suggestion will be appreciated. Thanks.
Songwei
Hi Songwei,
Welcome to the list and thank you for your interest in Mbed TLS!
I found a similar issue on stack overflow:
https://stackoverflow.com/questions/28895703/sbrk-function-not-found-when-p…
Is this the same issue as yours?
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de>
Date: Wednesday, 17 June 2020 at 10:49
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Link error when calling "altcp_tls_create_config_client"
Hi guys,
I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following:
c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
And these are my settings:
#define MBEDTLS_PLATFORM_C
#define MBEDTLS_PLATFORM_MEMORY
#define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc
#define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree
where chHeapAlloc and chHeapFree are the memory allocation functions from chibios.
(1) Did I miss some settings? or i did something wrong?
(2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs?
Any suggestion will be appreciated. Thanks.
Songwei
Hi All,
I am working on Renesas RZA2M embedded board with Linux. It has limited memory of 6MB flash(R-Only)
I am using mbedtls version 2.16.5 for aws iot sdk for embedded c according to
https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht…
When I run sample application, it is taking 15 secs for "Seeding random generator number..." and throwing below error
$ ./subscribe_publish_sample
AWS IoT SDK Version 3.0.1-
DEBUG: main L#159 rootCA /root/../certs/AmazonRootCA1.pem
DEBUG: main L#160 clientCRT /root/../certs/774a17950a-certificate.pem.crt
DEBUG: main L#161 clientKey /root/../certs/774a17950a-private.pem.key
Connecting...
DEBUG: iot_tls_connect L#130
. Seeding the random number generator...
DEBUG: iot_tls_connect L#138 . Loading the CA root certificate ...
DEBUG: iot_tls_connect L#144 ok (0 skipped)
DEBUG: iot_tls_connect L#146 . Loading the client cert. and key...
DEBUG: iot_tls_connect L#159 ok
DEBUG: iot_tls_connect L#161 . Connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443...
DEBUG: iot_tls_connect L#180 ok
DEBUG: iot_tls_connect L#182 . Setting up the SSL/TLS structure...
DEBUG: iot_tls_connect L#223
SSL state connect : 0
DEBUG: iot_tls_connect L#226 ok
DEBUG: iot_tls_connect L#228
SSL state connect : 0
DEBUG: iot_tls_connect L#229 . Performing the SSL/TLS handshake...
ERROR: iot_tls_connect L#232 failed
! mbedtls_ssl_handshake returned -0x50
ERROR: main L#190 Error(-4) connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com:443
For detailed debug log using ssl_client2, go through https://pastebin.com/mNXhB0xj<https://github.com/ARMmbed/mbedtls/issues/url>
https://pastebin.com/mNXhB0xj
my client device specifications
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1056.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
Hardware : Generic R7S9210 (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
$ free
total used free shared buffers cached
Mem: 7544 4484 3060 40 0 304
-/+ buffers/cache: 4180 3364
Swap: 0 0 0
I am not getting any help to resolve this issue and spending days and days. I am suspecting the issue might be timing related (or) cpu clock related (or) memory footprint related (or) something else
I need this forum help badly to resolve the issue. Please ping me if you need any other data.
Thanks in advance,
Srinivas.
Regards,
Srinivas.
[cid:1eddf249-06f8-4cbd-a3e2-9c22437fd27f]
Hi,
I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help.
Regards,
Fariya
Hi,
we have an application which uses ASIO. And now we want to add mbed TLS to
provide a TLS layer.
ASIO can be used with OpenSSL and wolfSSL. But how to do this with mbed TLS?
Any hints on that?
See also this question at SO:
https://stackoverflow.com/questions/61875404/asio-c-with-mbed-tls-library
best regards,
Frank
I want to connect an ESP32 to a DTLS server using mbedtls' dtls_server demo. The code I used for the client is very similar to the dtls_client example, but is unable to finish the handshake process for some reason. According to Wireshark, the client is not responding to the "Server hello done" frame, causing a timeout that makes the server to send the certificate again and again until it gives up the connection. The dtls_client demo works correctly on the computer, but not on the ESP32. Has anyone tested DTLS on the ESP32?
I have attached the following files for further reference:
- dtls_esp32.pcapng: Wireshark file with the DTLS packets between client and server.
- mbedtls.tar.bz2: compressed (> 7k lines) plain text log as reported by the board. On line 7131, where the last message from the server is received, it looks like the client never receives the whole message, so it never reaches the "Server hello done" state. Could anyone please confirm this?
- dtls.c: client source code. Slightly modified from the dtls_client example.
Thank you very much for your help.
Xavi
Hi,
I was reviewing the proposal and had a few questions on usage of the new params.
1) When using plaintext keys, is the "attributes" param unused and should/could it be set to NULL?
2) If using key store (i.e. opaque), is the key ID the only attribute field which needs to be set? My assumption is attributes would be populated from the key store using the key ID?
3) If using key store, are the "key_buffer" and "key_buffer_size" params typically unused (i.e. can be set to null and zero respectively)? I do the proposal says the buffer content is up to the driver. Are there any usage cases in mind?
4) For drivers that support both opaque and transparent operation, which param would be used to determine the mode? (I had assumed key ID = 0 would be transparent, and non-zero is opaque)
I'm unclear how persistent_state for opaque driver's is used. Could you elaborate on how it's used by the driver and core and why it isn't needed for transparent drivers?
Key management with opaque drivers
Transparent drivers may provide the following key management functions:
Should this be "Opaque"?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
> On 11 Jun 2020, at 12:09, Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote:
>
> On 11/06/2020 11:24, Martin Man via mbed-tls wrote:
>>
>> I think this is a bug and the dn_gets should simply leave the UTF-8
>> multibyte untouched when parsing it out from a field tagged with ASN.1
>> tag 12 (utf-8).
>
> We are not going to do Unicode normalization in Mbed TLS: that would be
> far too complex for a library that runs on systems with ~1e5 bytes
> available for code. So Unicode strings would only be processed correctly
> if the application passes normalized strings and CAs only generate
> certificates with normalized strings. But that would be an improvement
> on converting non-ASCII characters to '?'.
Definitely agree that normalization is not needed. I think this problem could be split into two parts:
1) When a const char* is passed into mbedtls_x509write_crt_set_subject_name, the mbedtls will currently encode it into ASN tag 12 UTF8. Not sure what validation is done. But it could perhaps do at least a basic validation of what the C string passed in is to avoid generating a cert with crippled DN. Alternatively you can simply trust the developer to pass in correct UTF8 and document this. This is a API design decision of what input is allowed to be passed into the method and what validation is done on this.
2) When the mbedtls_x509_dn_gets extracts a C string from the ASN.1 tagged as 12, it could validate that it is indeed valid UTF-8, or just leave it as is and push it out. Again, this is about what we expect the library to do.
I’m not an expert on whether this can in any way be used to trick MBEDLTS to do bad things when sending in a malformed certificate, say a one where DN is encoded as UTF-8 but contains illegal UTF-8 in the payload.
thanks for listening,
Martin