fix(cmake): support CMock subdir option with idf_component_mock (GitHub PR)
Closes IDFGH-14547 and IDFGH-12326
See merge request espressif/esp-idf!36761
In commit 70407df8c2 ("fix(build): don't call enable_language() before
proje.."), the C standard preferences were mistakenly changed to
`set(preferred_c_versions gnu99 gnu17 gnu11 gnu99)`. This was likely an
oversight from my testing. This corrects the C standard preferences to
the intended order.
Fixes: 70407df8c2 ("fix(build): don't call enable_language() before proje..")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Using same IV in AES-GCM across multiple invocation of
encryption/decryption operations can pose a security risk. It can help
to reveal co-relation between different plaintexts.
This commit introduces a change to use part of IV as a monotonic
counter, which must be incremented after every AES-GCM invocation
on both the client and the device side.
Concept of patch version for a security scheme has been introduced here
which can help to differentiate a protocol behavior for the provisioning
entity. The security patch version will be available in the JSON
response for `proto-ver` endpoint request with the field
`sec_patch_ver`.
Please refer to documentation for more details on the changes required
on the provisioning entity side (e.g., PhoneApps).
fix(bootloader_support): Fix SB verification failure when application is not signed with the boot loader's first key
Closes IDF-12556
See merge request espressif/esp-idf!37365
- Secure boot V2 verification failed when multiple keys are used to sign the bootloader
and the application is signed with a key other than the first key that is used to
sign the bootloader.
- The issue was introduced as a regression from the commit `ff16ce43`.
- Added a QEMU test for recreating the issue.
- Made SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT independent of SECURE_BOOT_BUILD_SIGNED_BINARIES.
For the Linux target, we currently attempt to fallback to older C/CXX
lagnuage standards in the __build_set_lang_version() function. The
language standard support is checked using CMake's language-specific
functions, such as check_c_compiler_flag(). These functions require the
language to be enabled[1] in CMake beforehand, which is done by calling
project() or by enabling the languages later with enable_language(). At
present, we use enable_language() to enable C and CXX languages in
CMake, allowing us to set the standard early, before invoking project().
However, newer CMake versions (>3.29) issue a warning[2] if
enable_language() is called before project(), as noted in CMP0165[3].
It should generally be acceptable to call __build_set_lang_version()
after __project(), but doing so would alter the behavior of the
COMPILE_OPTIONS also for non-Linux targets. Currently, users can
add to COMPILE_OPTIONS even before calling project() in the project's
CMakeLists.txt and the options will be in the desired order. In other
words, appending to COMPILE_OPTIONS can occur either before or after
calling project() in the project's CMakeLists.txt, with the outcome
remaining consistent. This means the user's settings will appear later
and take priority. However, if __build_set_lang_version() is called
after __project(), the user's COMPILE_OPTIONS settings would be
overridden if set before calling project(). Our documentation[4] explicitly
states that COMPILE_OPTIONS and similar properties should be modified
using idf_build_set_property() after calling project() to prevent
default values from overwriting them.
Even with this guidance, some existing components that modify
COMPILE_OPTIONS before invoking project() might be impacted by this
change. Therefore, separate the language standard settings for non-Linux
and Linux targets. For non-Linux targets, these settings are applied in
__build_set_default_build_specifications(), maintaining the current
behavior. For the Linux target, the language standard is set with
__linux_build_set_lang_version() after calling __project(), ensuring the
languages are already enabled in CMake and no warning is issued. Since the Linux
target is still in preview, this approach should be acceptable,
especially with the existing documentation[4].
Closes https://github.com/espressif/esp-idf/issues/15488
[1] https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#languages
[2] https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9396
[3] https://cmake.org/cmake/help/latest/policy/CMP0165.html#policy:CMP0165
[4] https://docs.espressif.com/projects/esp-idf/en/v5.4/esp32/api-guides/
build-system.html#overriding-default-build-specifications
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When minimal build is enabled, it only includes the main component and
its dependencies. This leads to test components specified through
TEST_COMPONENTS being ignored, meaning no tests are executed. The issue
arises because test components are also checked against the COMPONENTS
variable, and if they aren't listed there, they are disregarded. To fix
this, explicitly add TEST_COMPONENTS to COMPONENTS when the minimal
build is enabled.
Closes https://github.com/espressif/esp-idf/issues/15485
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The `idf_as_lib` example is used and tested in
`tools/test_build_system/test_cmake.py`. Include `idf_as_lib` in the
build_system rules to ensure the tests are executed whenever there is a
modification in the `idf_as_lib` example.
Expand the `test_build_custom_cmake_project` test to cover all supported
targets, including host build.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
ci: add python_func attribute and fix C testcase path resolution in JUnit reports
Closes RDT-1013, IDFCI-1990, IDFCI-1964, and IDFCI-1429
See merge request espressif/esp-idf!35058
This commit updates the following:
- Updates the panic handler to use only the RTC WDT to reset the system.
- Refactors some of the panic handler code.
- Updates Bluetooth files where in they now feed the WDTs instead of
reconfiguring them.
- Removes some unnecessary configuration of WDTs from various files.
- Added a unit test to verify that the system does not lock up when the
panic handler is stuck.
- Updates the memprot unit tests to work with the refactored panic
handler.
Closes https://github.com/espressif/esp-idf/issues/15166
Closes https://github.com/espressif/esp-idf/issues/15018
Closes https://github.com/espressif/esp-idf/issues/10110
Replace the original diag implementation in idf.py with the new one in a
separate esp-idf-diag python package. The interface is kept the same as
it was. The simple idf.py diag test is also preserved.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
