Add KASAN support for detecting heap memory safety bugs (buffer
overflows, underflows, use-after-free) at runtime using compiler
instrumentation and shadow memory. Gated behind
CONFIG_IDF_EXPERIMENTAL_FEATURES, with touch points kept to esp_system
and heap so other components stay untouched.
- Core runtime (esp_system/kasan.c, esp_kasan.h): nibble-based shadow
memory in DRAM, poison/unpoison, per-access validation, and __asan_*
stubs; hot-path stubs in IRAM so they stay valid with the flash cache
off. Shadow init runs before heap bring-up.
- Heap integration (heap/heap_kasan*.c): alloc/free hooks add redzones,
a quarantine FIFO, and shadow updates.
- Panic handling: disable checks once at the panic handler entry so
backtrace and stack dumps can read redzones without nested reports.
- Build system: -fsanitize=kernel-address for app code, with HAL, SoC,
esp_rom, SPI flash, esp_hw_support, bootloader_support, FreeRTOS, and
heap internals excluded from instrumentation.
- Test app (tools/test_apps/system/kasan_test): Unity tests for
overflow, underflow, use-after-free, and all sized __asan_* stubs,
with halt and no-halt configurations.
- Docs: document KASAN in the heap memory debugging guide (EN and CN).
test(vfs): Test changes regarding VFS register incorrect check fix and fix VFS host test not being run at all
See merge request espressif/esp-idf!49674
Wire esp_blockdev, comp_a, and comp_b into the test app dependency graph
so ioctl def files are registered and the POST_BUILD overlap checker runs.
Co-authored-by: Cursor <cursoragent@cursor.com>
Detect and drive the display-only ble_uart_vibe_indicator sample alongside
the interactive MiaoBan companion device, and let multiple OpenCode instances
each bind their own indicator channel.
- plugin: after connect, probe the device over the daemon's generic /request
path and classify it as vibe_indicator / generic / unknown — a vibe_indicator
answers the indicator_count capability query, a 502 marks a generic device,
and a transport failure stays unknown for retry on a later refresh. The daemon
stays a generic transport and is unchanged; detection is a demo concern.
- plugin: route by device_type. The vibe_indicator mirrors OpenCode activity
as four lamp states on its bound channel — executing (green blink),
success (green solid), waiting-for-user (yellow solid, on permission
prompts, decision left to the TUI), and error (red solid, on session.error
and the following idle). Other devices keep the existing session.status /
permission round-trip.
- plugin: add indicator_bind_channel / indicator_unbind_channel /
indicator_show_binding tools. Each channel has at most one live owner:
binding a channel owned by another running instance fails (force to take
over), and stale claims are reclaimed via process-liveness checks. The
per-directory binding is persisted and re-claimed across restarts
(OPENCODE_BLE_BINDING_FILE).
- docs: document device detection, lamp effects, and channel binding.
- Add type assertion for event.type to bypass strict TS compilation errors
- Accept both 'permission.asked' and 'permission.updated' event types
- Add normalizePermissionEvent() to handle internal vs SDK event property
format differences (pattern vs patterns, type vs permission fields)
- Add RawPermissionEvent type for loose event property parsing
- Add troubleshooting section and subdirectory auto-loading note to README
When an app sets __COMPONENT_REQUIRES_COMMON before project(), the
explicit value used to bypass the default branch that includes
${idf_target_arch}, dropping the arch component from the build.
IDF_TARGET_ARCH isn't known pre-project(), so apps shouldn't have to
hand-roll a target -> arch map. Append it after the explicit list during
common-component initialization; empty on linux means no append.
Read sdkconfig.cmake's CONFIG_* values and re-publish them on the
build-properties target so component CMakeLists.txt code that queries
Kconfig via idf_build_get_property(var CONFIG_FOO) returns the expected
value.
Add a COMMAND check on esptool_py_flash_target before invoking it in
__init_project_flash_targets. Apps that restrict the build set without
esptool_py would otherwise hit "Unknown CMake command".
Move managed-dependency injection and recursive inclusion to BEFORE the
component's add_subdirectory() call, so its CMakeLists.txt can resolve
managed-dep targets at register time. Inside idf_component_register,
union the manager-injected REQUIRES/PRIV_REQUIRES with what the
component author wrote instead of overwriting them.
Under __V1_COMPAT_SHIM, populate EXECUTABLE, EXECUTABLE_NAME, and
BUILD_COMPONENTS build properties in __project_default(), and propagate
project_elf to the caller scope. Relax the BUILD_COMPONENTS query gate
in build.cmake so component code that uses
idf_build_get_property(... BUILD_COMPONENTS) keeps working.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Replicate Build system v1 behavior where the 'main' component implicitly
depends on the discovered components (or the app-restricted
__SHIM_COMPONENTS list) when no explicit REQUIRES/PRIV_REQUIRES is set.
Gated on __V1_COMPAT_SHIM so native Build system v2 projects retain
their explicit dependency contract.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When IDF_BUILD_V2 evaluates to a CMake-truthy value, project.cmake
delegates to Build system v2 (cmakev2). The shim wraps project(),
forwards the app-declared COMPONENTS list via __SHIM_COMPONENTS, and
publishes __V1_COMPAT_SHIM so Build system v2 internals can gate Build
system v1 compatibility behavior. Existing app CMakeLists.txt files
build unchanged.
Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
Meet Patel
Dai Zi Yan
Roland Dobai
Jan Beran
Marek Fiala
Adam Múdry
Astha Verma
Martin Vychodil
Martin VychodilandCursor
Island
jiminxiang
Zhou Xiao
morris
Alexey Lapshin
Sudeep Mohanty
Tomáš Rohlínek
zhanghaipeng
Konstantin Kondrashov
Konstantin Kondrashov
Jiang Jiang Jian
Aditya Patwardhan
Jiang Guang MingandCursor
sibeibei