Skip to content
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

Merge latest fixes in from upstream (Apr through June) #29

Merged
merged 29 commits into from
Jul 9, 2022

Conversation

merge and others added 29 commits July 9, 2022 11:04
Trying to inherit the STM32F412xE target makes the linker fail, since
__CRASH_DATA_RAM_START__ is not present. Comparing LD scripts with the
STM32F412xG (which has active targets) it seems that the xE variant has
missed some updates somewhere. Since the LD scripts are otherwise
identical, copying the (working) ones from STM32F412xG seems to do the
trick.

Also added flash_data.h which was missing and needed here and there
(copied from xG and updated to fit the xE flash layout).
The Cordio stack uses a single CSRK. It can be used by a
malicious device to track the Mbed OS application if signed
writes are used.

Signed-off-by: Vincent Coubard <[email protected]>
The sleep_for function is updated to use the chrono time arguments since
the regular ones are deprecated.
The function SMSC9220_EMAC::low_level_input should create a heap for the
packet equal to the size of the message (most of which are couple hundred
bytes). The current code uses maximum frame size (1522 bytes) for each
packet. This will cause the heap to quickly fill up. In fact, the default
memory size (lwip.mem-size) used for this heap is 1600 bytes. This means
that once you have one other packet allocated (extremely common), the
heap allocation will always fails.

Also, it is recommend to increase the default lwip.mem-size because that
amount is very small especially if you send or receive a few large packets
in the network. This is NOT done in current commit.
The function smsc9220_receive_by_chunks loads data from the Ethernet port.
It is expected to return the Ethernet frame without the 4 CRC bytes.
However, it is required to call the Ethernet data port register (32-bit)
an amount equal to the number of frame words (including the 4 CRC bytes)
to pop all frame words. The current code doesn't call the register for the
last word (which has CRC data). This causes subsequent calls to have this
missed word at the beginning. The impact of this is huge as the high level
API is getting fed wrong data. The fix adds one additional call to the data
port register.
The functions smsc9220_receive_by_chunks and smsc9220_send_by_chunks are
supposed to implement receiving and sending packets by chunks. However,
the functions SMSC9220_EMAC::low_level_input and SMSC9220_EMAC::link_out,
which call them respectively, already require or assemble the full packet.
Also, smsc9220_receive_by_chunks doesn't implement the "chunks" part.

This commit renames the functions to smsc9220_receive_packet and
smsc9220_send_packet. The functions now do their operations by word
instead of by bytes. The functions SMSC9220_EMAC::low_level_input and
SMSC9220_EMAC::link_out already handle allocation, continuity and word
alignment of the packet buffer.
Engine doesn't support P + Q when P and Q are the same. Workaround by 2*P
In loading Curve448, MPI N is in uninitialized state and its sign flag N.s isn't initialized to 1.
This is fixed by following:
Mbed-TLS/mbedtls#5811
@multiplemonomials multiplemonomials merged commit d00ea7d into master Jul 9, 2022
@multiplemonomials multiplemonomials deleted the upstream-fixes branch July 9, 2022 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.