It was a cool talk. The attacker used a well timed glitch on voltage supply pin shared by the USB peripheral and OTP (one time programable) memory which unlike

It was a cool talk. The attacker used a well timed glitch on voltage supply pin shared by the USB peripheral and OTP (one time programable) memory which unlike the CPU power isn't protected by hardware glitch detectors. Instead the BootROM code does multiple validating reads to both known test values and the configuration bits. The glitch is timed to allow the test values to be read, but cuts power while reading the configuration bits. This causes test value to persist. It jus happens that the test value represents an invalid, but useful, configuration (both ARM and RISC-V cores disabled). The chip power on state machine boots the RISC-V cores in this case instead of hanging the start-up sequence. Since the RISC-V cores don't have a secure enclave mode their debug interface is always accessible if a RISC-V core is selected. The chip reset state machine is also partly under the control of software, because it's used to wakeup the chip from deep sleep modes. So the RISC-V cores (or their debug interface) can be used enable the ARM debug interface and perform a partial reset from beyond the point the state machine would disable the ARM debug interface, but early enough to reset everything else. It's my understanding there can be no pure software fix.