For ESP32-H2 case, the hardware k mode is always enforced through
efuse settings (done in startup code).
For ESP32-P4 case, the software k mode is not supported in the peripheral
itself and code was redundant.
In ESP32-H2, the ECDSA peripheral by default uses the TRNG (hardware)
generated k value but it can be overridden to software supplied k.
This can happen through by overriding the `ECDSA_SOFTWARE_SET_K` bit
in the configuration register. Even though the HAL API is not exposed
for this but still it could be achieved by direct register
programming. And for this scenario, if sufficiently random k is not
supplied by the software then it could posses a security risk.
In this change, we are unconditionally programming the efuse
`ESP_EFUSE_ECDSA_FORCE_USE_HARDWARE_K` bit during startup security
checks itself. Additionally, same is ensured in the `esp_efuse_write_key`
API as well. This always enforces the hardware k mode in the ECDSA
peripheral and ensures strongest possible security.
This commit adds a taskVALID_CORE_ID() macro, similar to the one offered in
Amazon SMP FreeRTOS.
- Various functions have been updated to use that macro
- Removed some unecessary static asserts of CONFIG_FREERTOS_NO_AFFINITY and
added casting.
- Uncrustify changes
1) Add parameter to configure reason code of deauth frame
2) Add logs to indicate MIC failure 4-Way-Handshake
3) Process RSNXE capabilities only if AP advertises them
This commit adds a subset of the DWC OTG configuration values to the
'usb_dwc_ll.h' file. Only relevant configuration values have been added.
Some DWC OTG releated constants have also been moved from 'usb_dwc_hal.h'
to 'usb_dwc_ll.h' and renamed.
This commit refactors SOC_USB_PERIPH_NUM as follows:
- Renamed to SOC_USB_OTG_PERIPH_NUM to avoid confusion with USB Serial JTAG
- Updated to unsigned integer "1U"
- Updated some build rules to depend on SOC_USB_OTG_SUPPORTED instead
fix(esp_pm): fix psram access failed after pd_cpu wakeup if uart driver driven console is used
Closes WIFIBUG-238
See merge request espressif/esp-idf!27020
Those dependencies are always satisfied because:
- ESP-IDF supports Python 3.8+ at this moment,
- click version is checked and ensured by the install scripts.
esp-system and esp-hw-support, and the rest of the g1 components, now only depend on
esp_driver_spi and esp_driver_gpio. Removing the rest of the driver components from g1 builds.
Adds 3 more ddisconnect reasons in case of No AP found.
1. REASON_NO_AP_FOUND_IN_RSSI_THRESHOLD : AP rejected because it did
not meet rssi threshold.
2. REASON_NO_AP_FOUND_IN_AUTHMODE THRESHOLD : AP rejected because it
did not meet security threshold.
3. REASON_NO_AP_FOUND_WITH_COMPATIBLE_ SECURITY : AP rejected because
of incompatible security configuration. These situations could include
-- bss offerring WEP, but our password is not WEP compliant,
-- Encrypted AP bss but we have no password config set.
-- AP is Enterprise but we have not setup enterprise config and vice versa
Closes https://github.com/espressif/esp-idf/issues/5957
