This commit sets the minimum required Zephyr SDK version to 0.13.1,
which fixes the following critical issues:
1. Xtensa initial malloc failure (GitHub issue #38258)
2. ARMv8-M security extension vulnerability (CVE-2021-35465)
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The commit 9bd1483afeb18f4225ec7b0340b0d4e20efb7d01 was added as a
workaround for the Xtensa initial malloc failure bug.
This bug has been fixed in the Zephyr SDK 0.13.1 release and therefore
this workaround is no longer needed.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
k_work_schedule may return other non-negative value than 0.
When driver was adapted to the new k_work API that was not
taken into account.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The Zephyr 2.6 release notes, in the Bluetooth section, refers the user
to a commit message which had a couple of typos in it. Clarify this in
the very release notes.
Fixes#36692.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
RFC 2460 Sec. 5 requires that a ICMPv6 Time Exceeded message is sent
upon reassembly timeout, if we received the first fragment (i.e. the one
with a Fragment Offset of zero).
Implement this requirement.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The purpose of shift_packets() is to make room to insert one fragment in
the list. This is not what it does currently, potentially leading to
-ENOMEM even if there is enough free room.
To see the current behaviour, let's assume that we receive 3 fragments
in reverse order:
- Frag3(offset = 0x40, M=0)
- Frag2(offset = 0x20, M=1)
- Frag1(offset = 0x00, M=1)
After receiving Frag3 and Frag2, pkt[] will look like:
.-------.-------.-------.
| Frag2 | Frag3 | NULL |
| 0x20 | 0x40 | |
'-------'-------'-------'
pkt[0] pkt[1] pkt[2]
When receiving Frag1, shift_packets(pos = 0) is called to make some room
at position 0. It will iterate up to i = 2 where there is a free
element. The current algorithm will try to shift pkt[0] to pkt[2], which
is indeed impossible but also unnecessary. It is only required to shift
pkt[0] and pkt[1] by one element in order to free pkt[0] to insert
Frag1.
Update the algorithm in order to shift the memory only by one element.
As a result, the ENOMEM test is only simpler: as long as we encounter
one free element, we are guaranteed that we can shift by one element.
Also assign a NULL value to the newly freed element since memmove() only
copy bytes.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently net_ipv6_handle_fragment_hdr() performs 2 distinct tests: it
checks the M-bit of the most recent fragment to decide if we can proceed
with the reassembly. Then it performs some sanity checks which can lead
to dropping the whole packet if not successful.
The test on the M-bit assumes that fragments arrive in order. But this
will fail if packets arrive out-of-order, since the last fragment can
arrive before some other fragments. In that case, we proceed with the
reassembly but it will fail because not all the fragments have been
received.
We need a more complete check before proceeding with the reassembly:
- We received the first fragment (offset = 0)
- All intermediate fragments are contiguous
- The More bit of the last fragment is 0
Since these conditions can also detect a malformed fragmented packet, we
can replace the existing sanity check that is performed before
reassembly. As a bonus, we can now detect and rejected overlapping
fragments, since this can have some security issues (see RFC 5722).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently we only store the fragment offset. But in some cases it might
be necessary to also inspect the M-bit (More Fragment) of all received
fragments.
Modify the semantics of the field to store all the flags, rename the
setter to account for this change, and add a getter for the M-bit.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The special handling of the 1st fragment in unnecessary, since it will
be correctly handled even without it. Moreover it causes some corner
cases, like a single packet with a fragment header (M=0), to be
incorrectly handled since the reassembly code is skipped.
Remove the special handling of the 1st fragment to fix these problems.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the requirement of the length being a multiple of 8 is not
tested for the first fragment, since the first fragment takes a
different path due to the goto.
Move the test earlier in the process, so that it is performed on all
fragments, including the first one.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
If we have less fragments than what can be stored in the reassembly
array, some loops will blindly dereference NULL pointers.
Add checks for NULL pointers when necessary and exit the loop.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the stack is limited to a maximum of 2 incoming fragments per
packet. While this can be enough in most cases, it might not be enough
in other cases.
Make this value configurable at build time.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently prev_hdr_offset always equals 6, which is the offset of
the nexthdr field in the IPv6 header. This value is used to overwrite it
when removing an IPv6 Fragment header, so it will work as long as there
is no other Extension header between the IPv6 header and the Fragment
header.
However this does not work in the other cases: the nexthdr field of the
IPv6 header will be overwritten instead of the nexthdr field of the last
Extension header before the Fragment, leading to unwanted results.
Update prev_hdr_offset so that it always point to the nexthdr field of
the previous header, either the IPv6 header or an Extension header.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current validation code waits to process the header before rejecting
it, while some checks can be already enforced when reading the nexthdr
field of the previous header.
The main problem is a wrong pointer field in the resulting ICMPv6 error
message: the pointer should have the offset of the invalid nexthdr
field, while currently it will the offset the invalid header.
To solve that problem, reorganize the loop in two parts: the first
switch validates nexthdr, while the second switch processes the current
header. This allows to reject invalid nexthdr earlier.
The check for duplicated headers is also generalized, so that we can
catch other kind of headers (like the Fragment header).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
By definition, NET_IPV6_NEXTHDR_NONE is void. So we must stop processing
before trying to read any data, since we will start reading values that
are outside the Extension Header (likely the payload, if any).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
When an unknown option is encountered, an ICMPv6 error message must be
sent in some cases. The message contains a pointer field, which must be
the offset to the unknown option. Currently the offset is computed from
the beginning of the option list, while it should be computed with
respect to the beginning of the IPv6 header.
Record the offset when reading the option type and pass it later to
ipv6_drop_on_unknown_option() to correctly set the pointer field. Also
rename the argument in ipv6_drop_on_unknown_option() to make the
purpose more clear.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently PADN data are not skipped, which results in the stack to think
that the next header starts in the middle of the padding. We have to
skip the bytes before going on.
Also clarify the PAD1 does not have any length field.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current names are confusing. Indeed "nexthdr" if the type of the
header currently processed, while "next_nexthdr" is the nexthdr field of
the current header.
Rename them to improve readability and make it less error-prone.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
ICMPv6 error messages are not sent (on native_posix) because the first
net_pkt_write() returns an error.
pkt has just been allocated using net_pkt_alloc_with_buffer(). Trying to
write an empty packet in overwrite mode will result in an error. There
is no need to be in overwrite mode, since we want to write the LL
src/dst addresses at the beginning.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
There is a copy-paste error in this sample code that results
in a function for input events being called for an output pin.
By chance, this has no influence on the behavior of the sample,
as the function returns a register offset that for events and
tasks is the same for a given channel, but obviously the code
is confusing.
This is fixed by replacing the relevant part with more suitable
function calls, to also simplify the code a little.
On the occasion, also a remark is added about no button debouncing
used in the sample, to prevent users from being surprised by its
possible behavior.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Similarly to what was done on stm32g0, disable DBGMCU clock
after operation to avoid conflict with openocd.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
If clock is not enabled write access on that registers are no-op.
Disable clock after operation to avoid conflicts with openocd which
can also access this clock when flashing.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Enable CONFIG_DEBUG when test is run in CI.
This will allow DGB access in stop modes (and specially flashing)
and avoid potential issues when test in run in a test suite.
Note that on some targets (stm32wb for instance) openocd is able
to do the same operation, and which allows to reflash the target
even if switch was not enabled, but this could not be the case
on all targets.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Adding missing parenthesis. Without them wrong results
appeared when k_cycle_get_32 wrapped.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Fixes: #38463
With 6be1b2af9b then Zephyr shields and
soc Kconfig are always sourced from Kconfig directly.
However, check_compliance.py generates Kconfig files for sourcing the
same files thus sourcing the same files twice.
The end result is a lot of Kconfig warnings as described in #38463.
Removing the generated Kconfig files as this is no longer needed after
6be1b2af9b has been introduced.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #38761
The introduction of zephyr_library_property in #38347 contained a
stray function call `target_compile_definitions()` resulting in the
library property name and value to also be added compile definitions to
the Zephyr library.
The Zephyr library property is an internal property and is not supposed
to be added as compile definitions, and thus this call is removed with
this commit.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add support for Quectel modem in gsm_ppp modem driver.
The CMUX cmd is based on MUX application notes v1.0(2020-09-22)
for BG95, BG77 and BG600L. Tested and working on EC21e.
As the gsm_ppp doesn't do power control, it is required to power
on the modem manually in the application.
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Apply the same changes as the previous commit made in the spi_nrfx_spim
shim, to keep these two shims aligned.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, for 32 Mbps high-speed SPI using SPIM4,
drive configuration H0H1 must be used. The underlying nrfx_spim driver
does it properly in its initialization function, so change the shim to
(re)initialize the driver when the SPI configuration is to be changed
(only then the speed to use is known), to avoid the need of duplicating
the corresponding code in the shim itself.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, SPIM4 only supports 32 Mbps when
the application core is running at 128 MHz. This patch adds
the corresponding check.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The board name used in the zephyr-app-commands directive was the old
name for the Thingy52 board.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The nRF battery sample claims that it works without the need of a vbatt
node (voltage divider). However, this was currently not possible because
the sample code did have no means to extract the necessary ADC details
(instance and channel) from Devicetree unless vbatt was present. Similar
to other ADC samples, the zephyr,user node is used to define io-channels
property in this case. The sample README has been updated with an
example of how measurement without a voltage divider can be achieved.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
GDB can be built with or without Python support. When built with Python
support this can cause a particular problem: The gdb executable relies
on shared libraries that are bound to a specific Python version. But
since most Linux distributions typically ship with a single version, it
is very difficult to choose which one to target when building GDB.
When GDB executes, if it fails to load the shared libraries it will exit
immediately with an error code of 127 and output resembling this:
/home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb:
error while loading shared libraries: libpython3.8.so.1.0: cannot open
shared object file: No such file or directory
There are two known approaches to shipping multiple gdb executables:
- The Zephyr SDK ships a default gdb with Python enabled, and then a
separate gdb-no-py executable with Python disabled
- GNU Arm Embedded ships with a default gdb with Python disabled, and an
additional gdb-py with Python enabled
To mitigate the problem of not being able to debug, fall back to a
'gdb-no-py' if it exists whenever the standard gdb executable fails to
even run.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Refactor IPv4 multicast address to MAC multicast address conversion
into its own function, so it can be reused by drivers as it is already
possible for IPv6 multicast addresses.
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
This patch fixes the issue that can cause a deadlock in shell.
When two threads simultaneously poll the TXDONE signal, only one
of them will receive it, leaving second one stalled.
The problem was that shell's context contains k_poll_event objects that
were polled by multiple threads. Polling it overwrites the poller field
that was set by previous thread.
Instead, the k_poll_event object must be created on the stack by every
thread that wants to poll the TXDONE signal.
This makes sure that no thread will be left waiting for this signal
forever.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
ptp_clock_test was failing when trying to access the ptp clock from user
mode. This was due to an arbitrary initialization priority between the
virtual PTP clock devices created by the ptp clocking test and the
physical PTP clock on the frdm_k64f board. Since the ptp test
initializes the virtual clock with the same device name as the physical
clock, if the physical clock was initialized first this test would
incorrectly reference the physical device during testing, instead of the
virtual one.
This fix simply defines the virtual ptp clock with a custom name, so
that the test will always locate the correct ptp clock.
Fixes#38731
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Ensure the GPRS connection APN settings match the PDP
context. This it best to ensure proper IP connectivity.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
Ensure that the IP family is synchronized between the PDP
context and the GPRS connection.
There were cases where they could get out of sync.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
Assign the IPv6 address from the LTE network to the
network iface.
Configure DNS resolver with IPv6 DNS address from the
LTE network.
Fix socket AT commands to account for IPv6 addresses.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
In the DNS work callback ensure the iface is up
(on the LTE network) before trying to reconfigure the
DNS resolver with the DNS address.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
When falling back to L2CAP for connection parameter updates, the
interval min and maxes should also be saved.
Fixes#38613.
Signed-off-by: Eric Johnson <eric@liveathos.com>
The stm32wl version of the sx126x driver disables the NVIC interrupt in
the radio isr to prevent retriggering while the event gets handled in
the workqueue. Since the interrupt condition is still present while the
line is disabled, the interrupt pending bit remains set in the NVIC, so
after the handler finished, when irq_enable() gets called, the interrupt
fires immediately again with no status bit set in the radio registers.
Apart from the no-op interrupt, this has the side effect of bringing
the radio out of sleep as soon as the interrupt bit are read and
cleared, which increases the idle state power consumption.
Adding a NVIC_ClearPendingIRQ() before irq_enable() seems to fix the
problem. It should not cause any issue with missing interrupt events, as
if there are pending bit on the Radio, the NVIC pending bit would be
re-set immediately.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
1. Add support for multiple syscon entries (as a side effect, this also
fixed syscon.c implementations which weren't being linked to their
syscon.h counterparts).
2. Add support for different width registers in syscon.
3. Add tests for syscon
Signed-off-by: Yuval Peress <peress@chromium.org>
Since version 1.11.0, Full stack M0 binary requires 216K of flash
being available, while previously 212K were required.
Review flash partitioning to take it into account.
Additionally:
- update value in board yaml file.
- align value in package .dtsi file
Fixes#38735
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
