Implement the NAN Data Path encrypted datapath per Wi-Fi Aware v4.0
(§7.1.3.5, §9.5.16):
- Responder + initiator sides of the M1-M4 Shared-Key Descriptor
exchange, with MIC compute/verify, PTK derivation, and PMK/PMKID
derivation via PBKDF2-SHA256 over passphrase or pre-shared PMK.
- CSIA / SCIA attribute build + parse, NCS-SK-128 cipher suite.
- Per-NDL security context on ndl_info::security_ctx; per-svc PMK cache.
- ndp_response_indication callback for initiator peer-NDI binding.
- host<->blob ABI migrated from 27 direct esp_nan_* externs to a single
nan_secure_dp_funcs callback struct in esp_private/wifi.h.
- nan_security.c split out of nan_app.c (~340 lines de-duplicated into
shared M1-M4 helpers).
- CONFIG_ESP_WIFI_NAN_ENCRYPTED_DATAPATH gates the secure path so non-
security builds compile out the crypto/handshake code.
- ROM patch (esp32s31): mask ieee80211_encap_esfbuf to match the
c5/c6/c61 pattern for NAN-capable chips.
Hardening: PMK stack copies zeroized on every return, NDP attribute
parsers bounds-checked, CSID range-checked before shifting, NDL slot
reuse only when handshake state is IDLE, get_csia/scia_len aligned with
their builders on empty input.
API surface: NDP security types moved out of esp_wifi_types_generic.h
into esp_private/wifi.h (internal-only). security pointer dropped from
struct ndp_cb_peer_info. Discovery-side wifi_nan_security_type_t and
the NDP Info callbacks removed (subsumed by csid_bitmap and SSI
respectively).
Applicable for chips affected by interrupt issue:
- ESP32C5
- ESP32C61
- ESP32H4
For all other chips that support the ZCMP extension without issues,
it will be enabled unconditionally.
Introduce ESPTOOLPY_FAST_REFLASHING configuration option. It instructs
ldgen to group entity mappings for libraries deemed mutable (prone to
change) separately from those considered immutable (unlikely to change).
Organizing mutable and immutable libraries separately in the linker
script allows the linker to form larger contiguous blocks of data for
immutable libraries in the application's output sections. These blocks
are likely to stay mostly unchanged between application recompilations,
enabling them to be skipped during reflashing.
Separating mutable and immutable libraries in the linker script to
minimize changes in the output sections is insufficient. Padding is
added after the input sections of mutable libraries in the default data
and text output sections. This creates a buffer for the mutable
libraries, allowing additional changes to be made without altering the
layout of the binary image.
Additionally two optimizations currently in use can still mix data from
these libraries, leading to significant changes even within the grouped
immutable libraries.
1. constant merging
Linker will try to merge input sections that have the MERGE and
STRING flags from different libraries (object files) to perform
optimizations like tail merging. For example, adding a string
literal in a mutable library will also change the addresses of
string literals from immutable libraries in such a merged section,
causing changes in the generated code when those literals are
referenced.
Disabled with COMPILER_DISABLE_MERGE_CONSTANTS(-fno-merge-constants)
2. literal pools on Xtensa
As optimization, the linker may merge literal pools from different
libraries (object files) to improve the generated code size. This
has the same effect as constant merging, and changes in mutable
libraries may cause changes in the generated code for immutable
libraries. To get larger unchanged continuous blocks in the text
output sections for immutable libraries, we need to ensure that the
Xtensa literal pools remain close to their references and are not
merged.
Disabled with CONFIG_COMPILER_ENABLE_TEXT_SECTION_LITERALS(-mtext-section-literals)
When ESPTOOLPY_FAST_REFLASHING is enabled, these two optimizations are
disabled to achieve larger unchaged continuous blocks for the grouped
immutable libraries, even though disabling these optimizations results
in slightly larger code.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently both menu configs, for component's project configuration and
component's configuration, for components not included in the build have
the same name: "Configuration for components not included in the build".
This might be confusing. Let's use "Project configuration for components
not included in the build" for component Kconfig.projbuild files.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Introduce new configuration menus for components that are not part of
the build. These menus will only be visible if the IDF_BUILD_V2
environment variable is defined and it will be set only in cmakev2. This
enables sharing of the root Kconfig file between cmakev1 and cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Allow to disable implicit inlining of constexpr functions from libstdc++.
This is a known GCC issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
that may affect C++ application size depending on its structure.
