Possible for a joined task to be deleted at the moment it is logging,
meaning it might hold the stdout lock. In that case the lock isn't
released and the next task to try and take it (i.e. call printf)
will block indefinitely.
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
Add support to tasks stacks in RTC DRAM. Before this fix, any stack
in RTC DRAM would have been considered as corrupted, whichi is not
the case.
Fix a bug related to wrong parameters passed to esp_core_dump_get_stack.
Fix a bug reading fake stack memory, triggering a memory violation.
* Closes https://github.com/espressif/esp-idf/issues/6751
* Merges https://github.com/espressif/esp-idf/pull/6750
Building mbedtls with CMake would warn that:
"A private source from a directory other than that of target "mbedcrypto
has a relative path"
This happened due to some of the CMake variables listing sources could be empty.
Changed to only use target_sources in the code-path where we set the sources,
so we only call target_sources will non-empty variables.
Closes https://github.com/espressif/esp-idf/issues/6767
NimBLE: Add NimBLE host support to reattempt GAP connection and address MITM vulnerability (CVE-2020-26558) (release/v4.3)
See merge request espressif/esp-idf!13549
* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
Since dd849ffc, _rodata_start label has been moved to a different
linker output section from where the TLS templates (.tdata, .tbss)
are located. Since link-time addresses of thread-local variables are
calculated relative to the section start address, this resulted in
incorrect calculation of THREADPTR/$tp registers.
Fix by introducing new linker label, _flash_rodata_start, which points
to the .flash.rodata output section where TLS variables are located,
and use it when calculating THREADPTR/$tp.
Also remove the hardcoded rodata section alignment for Xtensa targets.
Alignment of rodata can be affected by the user application, which is
the issue dd849ffc was fixing. To accommodate any possible alignment,
save it in a linker label (_flash_rodata_align) and then use when
calculating THREADPTR. Note that this is not required on RISC-V, since
this target doesn't use TPOFF.
It is now possible to have any alignment restriction on rodata in the user
applicaiton. It will not affect the first section which must be aligned
on a 16-byte bound.
Closes https://github.com/espressif/esp-idf/issues/6719
rodata dummy section has now the same alignment as flash text section,
and at least the same size. For these reasons, the cache will map
correctly the following rodata section.
