8000 esp32: mbedtls can't allocate in/out buffers on IDF4.x · Issue #5303 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

esp32: mbedtls can't allocate in/out buffers on IDF4.x #5303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jimmo opened this issue Nov 7, 2019 · 4 comments
Closed

esp32: mbedtls can't allocate in/out buffers on IDF4.x #5303

jimmo opened this issue Nov 7, 2019 · 4 comments

Comments

@jimmo
Copy link
Member
jimmo commented Nov 7, 2019

Raised at https://forum.micropython.org/viewtopic.php?f=18&t=7208

At the point that modussl_mbedtls.c calls mbedtls_ssl_setup, the ESP32 heap looks like this:

Heap summary for capabilities 0x00001800:
  At 0x3ffaff10 len 240 free 0 allocated 168 min_free 0
    largest_free_block 0 alloc_blocks 10 free_blocks 0 total_blocks 10
  At 0x3ffb6388 len 7288 free 0 allocated 7168 min_free 0
    largest_free_block 0 alloc_blocks 22 free_blocks 0 total_blocks 22
  At 0x3ffb9a20 len 16648 free 0 allocated 16324 min_free 0
    largest_free_block 0 alloc_blocks 73 free_blocks 0 total_blocks 73
  At 0x3ffcc870 len 79760 free 26808 allocated 52520 min_free 19840
    largest_free_block 26716 alloc_blocks 94 free_blocks 6 total_blocks 100
  At 0x3ffe0440 len 15072 free 15036 allocated 0 min_free 15036
    largest_free_block 15036 alloc_blocks 0 free_blocks 1 total_blocks 1
  At 0x3ffe4350 len 113840 free 4092 allocated 109708 min_free 4092
    largest_free_block 4092 alloc_blocks 1 free_blocks 1 total_blocks 2
  Totals:
    free 45936 allocated 185888 min_free 38968 largest_free_block 26716

mbedtls_ssl_setup tries to allocate two 16717 buffers -- the first (ssl->in_buf) succeeds (likely from the fourth block) then the second (ssl->out_buf ) fails.

Easy workaround would be to enable CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN (which would drop the output buffer to 4kiB).

I'll grab the heap info for a 3.3 build. I'm guessing that by chance the fragmentation across the blocks just ends up being slightly more favourable to two >16kiB allocations.

@dpgeorge
Copy link
Member
dpgeorge commented Nov 7, 2019

I didn't know that it's possible to configure the in/out SSL content lengths separately in mbedtls. IMO it'd be good to enable this feature on all ports that use mbedtls, because otherwise SSL connections cost a lot of RAM (ie 16k for incoming, to support all servers, but 4k or so on outgoing data).

@jimmo
Copy link
Member Author
jimmo commented Nov 7, 2019

OK, I will send a PR to do that.

However, looking at the heap summary in 3.3 (below) is quite interesting and clearly shows why this problem exists now -- there used to be a 154504 byte region in 3.3 which is now split into 79760 + 16648 + 15072 in 4.x.

Heap summary for capabilities 0x00001800:
  At 0x3ffae6e0 len 6432 free 0 allocated 6276 min_free 0
    largest_free_block 0 alloc_blocks 31 free_blocks 0 total_blocks 31
  At 0x3ffba478 len 154504 free 0 allocated 154120 min_free 0
    largest_free_block 0 alloc_blocks 88 free_blocks 0 total_blocks 88
  At 0x3ffe0440 len 15072 free 0 allocated 14968 min_free 0
    largest_free_block 0 alloc_blocks 18 free_blocks 0 total_blocks 18
  At 0x3ffe4350 len 113840 free 94508 allocated 19124 min_free 87416
    largest_free_block 94448 alloc_blocks 40 free_blocks 4 total_blocks 44
  Totals:
    free 94508 allocated 194488 min_free 87416 largest_free_block 94448

The 3.3 MicroPython heap is 115008 bytes which came from that now-split 154504 region. On 4.x the MicroPython heap (now 107136 bytes) comes from that 113840 byte region instead.

@jimmo
Copy link
Member Author
jimmo commented Nov 7, 2019

A consequence of this fragmentation is that even though setting CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN fixes the reported issue, it will fail to allocate a second concurrent ssl socket. Whereas in 3.3 it could support two concurrent sockets (or 4 with CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN).

jimmo added a commit to jimmo/micropython that referenced this issue Nov 7, 2019
jimmo added a commit to jimmo/micropython that referenced this issue Nov 7, 2019
dpgeorge pushed a commit that referenced this issue Nov 11, 2019
The IDF heap is more fragmented with IDF 4 and mbedtls cannot allocate
enough RAM with 16+16kiB for both in and out buffers, so reduce output
buffer size.

Fixes issue #5303.
@dpgeorge
Copy link
Member

It seems IDF 4 (in its current development state) uses quite a bit more RAM than IDF 3. That's a good reason to keep support for IDF 3, and look into #5282

The issue here with mbedtls allocation is fixed by 71299d3, so I'll close this issue.

dpgeorge pushed a commit that referenced this issue Dec 20, 2019
To reduce the size of the SSL context on the heap.  See issue #5303.
alu96 pushed a commit to alu96/micropython that referenced this issue Mar 23, 2020
The IDF heap is more fragmented with IDF 4 and mbedtls cannot allocate
enough RAM with 16+16kiB for both in and out buffers, so reduce output
buffer size.

Fixes issue micropython#5303.
alu96 pushed a commit to alu96/micropython that referenced this issue Mar 23, 2020
To reduce the size of the SSL context on the heap.  See issue micropython#5303.
c0d3z3r0 pushed a commit to c0d3z3r0/micropython that referenced this issue Apr 5, 2020
The IDF heap is more fragmented with IDF 4 and mbedtls cannot allocate
enough RAM with 16+16kiB for both in and out buffers, so reduce output
buffer size.

Fixes issue micropython#5303.
c0d3z3r0 pushed a commit to c0d3z3r0/micropython that referenced this issue Apr 5, 2020
To reduce the size of the SSL context on the heap.  See issue micropython#5303.
tannewt pushed a commit to tannewt/circuitpython that referenced this issue Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
0