espefuse burn_key doesn't get saved in virtual mode (ESPTOOL-1094)

[j4k0xb]

Operating System

Manjaro Linux

Esptool Version

v4.9.0

Python Version

Python 3.13.3

Full Esptool Command Line that Was Run

espefuse.py --chip esp32s3 --do-not-confirm --debug --virt --path-efuse-file build/qemu_efuse.bin burn_key --show-sensitive-info BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY

Esptool Output

espefuse.py v4.9.0
BLOCK0          (                ) [0 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
MAC_SPI_8M_0    (BLOCK1          ) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA  (BLOCK2          ) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_USR_DATA  (BLOCK3          ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1      (BLOCK5          ) [5 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2      (BLOCK6          ) [6 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3      (BLOCK7          ) [7 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4      (BLOCK8          ) [8 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5      (BLOCK9          ) [9 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10         ) [10] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

BLOCK0          (                ) [0 ] err__regs: 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE_RD_RS_ERR0_REG        0x00000000
EFUSE_RD_RS_ERR1_REG        0x00000000

=== Run "burn_key" command ===
Burn keys to blocks:
 - BLOCK_KEY0 -> [39 ff 18 c0 94 26 18 8f f7 ae 3a 7f fc 1b 7c 83 be 7e 2a 84 a6 02 dd 83 ae 2e f7 c8 d1 13 48 46]
        Reversing byte order for AES-XTS hardware peripheral
        'KEY_PURPOSE_0': 'USER' -> 'XTS_AES_128_KEY'.
        Disabling write to 'KEY_PURPOSE_0'.
        Disabling read to key block
        Disabling write to key block


Check all blocks for burn...
idx, BLOCK_NAME,          Conclusion
[00] BLOCK0               is empty, will burn the new value
[01] MAC_SPI_8M_0         nothing to burn
[02] BLOCK_SYS_DATA       nothing to burn
[03] BLOCK_USR_DATA       nothing to burn
[04] BLOCK_KEY0           is empty, will burn the new value
[05] BLOCK_KEY1           nothing to burn
[06] BLOCK_KEY2           nothing to burn
[07] BLOCK_KEY3           nothing to burn
[08] BLOCK_KEY4           nothing to burn
[09] BLOCK_KEY5           nothing to burn
[10] BLOCK_SYS_DATA2      nothing to burn
. 
This is an irreversible operation!
BLOCK_KEY0      (BLOCK4          ) [4 ] to_write: c018ff39 8f182694 7f3aaef7 837c1bfc 842a7ebe 83dd02a6 c8f72eae 464813d1
Write data to BLOCK4
Addr 0x60007000, data=0xc018ff39
Addr 0x60007004, data=0x8f182694
Addr 0x60007008, data=0x7f3aaef7
Addr 0x6000700c, data=0x837c1bfc
Addr 0x60007010, data=0x842a7ebe
Addr 0x60007014, data=0x83dd02a6
Addr 0x60007018, data=0xc8f72eae
Addr 0x6000701c, data=0x464813d1
Addr 0x60007020, data=0x19731ec4
Addr 0x60007024, data=0x75c2c852
Addr 0x60007028, data=0x4ebeee5b
BLOCK_KEY0 4ebeee5b75c2c85219731ec4464813d1c8f72eae83dd02a6842a7ebe837c1bfc7f3aaef78f182694c018ff39
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: c018ff39 8f182694 7f3aaef7 837c1bfc 842a7ebe 83dd02a6 c8f72eae 464813d1
BURN BLOCK4  - OK (write block == read block)
BLOCK0          (                ) [0 ] to_write: 00800100 00000001 04000000 00000000 00000000 00000000
Write data to BLOCK0
Addr 0x60007000, data=0x00800100
Addr 0x60007004, data=0x00000001
Addr 0x60007008, data=0x04000000
Addr 0x6000700c, data=0x00000000
Addr 0x60007010, data=0x00000000
Addr 0x60007014, data=0x00000000
Addr 0x60007018, data=0x00000000
Addr 0x6000701c, data=0x00000000
BLOCK0 0000000000000000000000000000000000000000040000000000000100800100
BLOCK0          (                ) [0 ] read_regs: 00800100 00000001 04000000 00000000 00000000 00000000
BURN BLOCK0  - OK (write block == read block)
Reading updated efuses...
BLOCK0          (                ) [0 ] read_regs: 00800100 00000001 04000000 00000000 00000000 00000000
MAC_SPI_8M_0    (BLOCK1          ) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA  (BLOCK2          ) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_USR_DATA  (BLOCK3          ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1      (BLOCK5          ) [5 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2      (BLOCK6          ) [6 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3      (BLOCK7          ) [7 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4      (BLOCK8          ) [8 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5      (BLOCK9          ) [9 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10         ) [10] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Successful

What is the Expected Behaviour?

Save key to BLOCK_KEY0

More Information

With --no-read-protect it gets saved but qemu_efuse.bin size will also be truncated to 512 bytes.

Other Steps to Reproduce

• Created key with espsecure.py generate_flash_encryption_key flash_encryption_key.bin
• Created empty efuses file with dd if=/dev/zero bs=1K count=1 of=build/qemu_efuse.bin

[github-actions]

Hi @j4k0xb! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Thank you for your detailed report. Based on the Espressif documentation, the espefuse tool supports a virtual mode using the --virt flag, which allows you to test eFuse operations without physical hardware. When used with --path-efuse-file, the tool should save the eFuse memory to the specified file, and deleting this file resets the eFuses. This is intended to let you persist changes between commands in virtual mode:

Using --path-efuse-file, you can save the written data to a file. Delete the file to clear eFuses.
Usage: --path-efuse-file efuse_memory.bin
espefuse documentation for ESP32-S3

However, the documentation does not provide details about any limitations or known issues regarding the persistence of burned keys in virtual mode, nor does it mention the file size being truncated or keys not being saved unless --no-read-protect is used.

Summary:

• According to the official documentation, using --virt with --path-efuse-file should persist eFuse changes, including burned keys, to the specified file.
• The behavior you are seeing (key not saved unless --no-read-protect is used, and file size truncated) is not described in the Espressif documentation.
• There is no mention in the knowledge sources of any requirement to use --no-read-protect for keys to be saved in virtual mode, nor of file size issues.

Recommendation:
This appears to be either a bug or an undocumented limitation in the current version of espefuse.py. I recommend reporting this behavior to the Espressif team for further investigation, as the expected behavior is that the key should be saved to the file regardless of the read protection setting, and the file size should not be unexpectedly truncated.

If you need to reference the official documentation for your issue, you can point to the section describing virtual mode and file persistence:
espefuse virtual mode and file persistence

If you have further questions or need clarification, please let me know!

[KonstantinKondrashov]

Hi @j4k0xb!
Flash encryption key is read and write-protected. So it is the right behavior that you do not see the written key.
You have to use --no-read-protect to get the FE key in the file; otherwise, the efuse tool will hide it as the efuse controller does.

You have to do it a bit differently. Here is an example that you can adapt for your goal to create an efuse file for qemu.

1. You may wish to dump the efuse from your real chip, because it includes some important settings like chip version, MAC, and others. (If you do not have one, you may need to set them manually if needed).

espefuse.py --chip=esp32s3 dump --format split --file_name real_efuse_blocks/block.bin

2. Burn some efuse blocks from the real chip (BLOCK0-BLOCK3), SB and FE keys, and dump all of it to a file that is suitable for qemu.

espefuse.py --chip=esp32s3 --virt \
burn_block_data BLOCK0 real_efuse_blocks/block0.bin \
burn_block_data BLOCK1 real_efuse_blocks/block1.bin \
burn_block_data BLOCK2 real_efuse_blocks/block2.bin \
burn_block_data BLOCK3 real_efuse_blocks/block3.bin \
burn_efuse SECURE_BOOT_EN \
burn_key BLOCK_KEY0 digest.bin SECURE_BOOT_DIGEST0 \
burn_efuse SPI_BOOT_CRYPT_CNT \
burn_key BLOCK_KEY1 my_flash_encryption_key.bin XTS_AES_128_KEY --no-read-protect \
summary \
dump --format joint --file_name build/qemu_efuse.bin

For your information, --path-efuse-file build/qemu_efuse.bin does not fit the same structure as qemu expects; you have to use dump --format joint for that.

[j4k0xb]

Thanks for the answer.
However the problem isn't about displaying, but that the key bytes are also never saved to the file (offset 0x70-0x8F stays at 0):

When running the exact same burn command with --port it works despite being write and read protected, so there must be some difference in how the qemu efuse controller and virtual efuse controller are implemented.

qemu-system-xtensa -nographic \
                    -machine esp32s3 \
                    -global driver=esp32s3.gpio,property=strap_mode,value=0x07 \
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32s3.efuse,property=drive,value=efuse \
                    -serial tcp::5555,server,nowait

espefuse.py --chip esp32s3 --do-not-confirm --debug --port socket://localhost:5555 burn_key --show-sensitive-info BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY

espefuse.py v4.9.0
Note: It's not possible to reset the chip over a TCP socket. Automatic resetting to bootloader has been disabled, reset the chip manually.
Connecting...
Device PID identification is only supported on COM and /dev/ serial ports.

BLOCK0          (                ) [0 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
MAC_SPI_8M_0    (BLOCK1          ) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA  (BLOCK2          ) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_USR_DATA  (BLOCK3          ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1      (BLOCK5          ) [5 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2      (BLOCK6          ) [6 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3      (BLOCK7          ) [7 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4      (BLOCK8          ) [8 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5      (BLOCK9          ) [9 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10         ) [10] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

BLOCK0          (                ) [0 ] err__regs: 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE_RD_RS_ERR0_REG        0x00000000
EFUSE_RD_RS_ERR1_REG        0x00000000

=== Run "burn_key" command ===
Burn keys to blocks:
 - BLOCK_KEY0 -> [39 ff 18 c0 94 26 18 8f f7 ae 3a 7f fc 1b 7c 83 be 7e 2a 84 a6 02 dd 83 ae 2e f7 c8 d1 13 48 46]
        Reversing byte order for AES-XTS hardware peripheral
        'KEY_PURPOSE_0': 'USER' -> 'XTS_AES_128_KEY'.
        Disabling write to 'KEY_PURPOSE_0'.
        Disabling read to key block
        Disabling write to key block


Check all blocks for burn...
idx, BLOCK_NAME,          Conclusion
[00] BLOCK0               is empty, will burn the new value
[01] MAC_SPI_8M_0         nothing to burn
[02] BLOCK_SYS_DATA       nothing to burn
[03] BLOCK_USR_DATA       nothing to burn
[04] BLOCK_KEY0           is empty, will burn the new value
[05] BLOCK_KEY1           nothing to burn
[06] BLOCK_KEY2           nothing to burn
[07] BLOCK_KEY3           nothing to burn
[08] BLOCK_KEY4           nothing to burn
[09] BLOCK_KEY5           nothing to burn
[10] BLOCK_SYS_DATA2      nothing to burn
. 
This is an irreversible operation!
BLOCK_KEY0      (BLOCK4          ) [4 ] to_write: c018ff39 8f182694 7f3aaef7 837c1bfc 842a7ebe 83dd02a6 c8f72eae 464813d1
Write data to BLOCK4
Addr 0x60007000, data=0xc018ff39
Addr 0x60007004, data=0x8f182694
Addr 0x60007008, data=0x7f3aaef7
Addr 0x6000700c, data=0x837c1bfc
Addr 0x60007010, data=0x842a7ebe
Addr 0x60007014, data=0x83dd02a6
Addr 0x60007018, data=0xc8f72eae
Addr 0x6000701c, data=0x464813d1
Addr 0x60007020, data=0x19731ec4
Addr 0x60007024, data=0x75c2c852
Addr 0x60007028, data=0x4ebeee5b
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: c018ff39 8f182694 7f3aaef7 837c1bfc 842a7ebe 83dd02a6 c8f72eae 464813d1
BURN BLOCK4  - OK (write block == read block)
BLOCK0          (                ) [0 ] to_write: 00800100 00000001 04000000 00000000 00000000 00000000
Write data to BLOCK0
Addr 0x60007000, data=0x00800100
Addr 0x60007004, data=0x00000001
Addr 0x60007008, data=0x04000000
Addr 0x6000700c, data=0x00000000
Addr 0x60007010, data=0x00000000
Addr 0x60007014, data=0x00000000
Addr 0x60007018, data=0x00000000
Addr 0x6000701c, data=0x00000000
BLOCK0          (                ) [0 ] read_regs: 00800100 00000001 04000000 00000000 00000000 00000000
BURN BLOCK0  - OK (write block == read block)
Reading updated efuses...
BLOCK0          (                ) [0 ] read_regs: 00800100 00000001 04000000 00000000 00000000 00000000
MAC_SPI_8M_0    (BLOCK1          ) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA  (BLOCK2          ) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_USR_DATA  (BLOCK3          ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0      (BLOCK4          ) [4 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1      (BLOCK5          ) [5 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2      (BLOCK6          ) [6 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3      (BLOCK7          ) [7 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4      (BLOCK8          ) [8 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5      (BLOCK9          ) [9 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10         ) [10] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Successful

=== Run "summary" command ===
EFUSE_NAME (Block) Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Config fuses:
WR_DIS (BLOCK0)                                    Disable programming of individual eFuses           = 8388864 R/W (0x00800100)
RD_DIS (BLOCK0)                                    Disable reading from BlOCK4-10                     = 1 R/W (0b0000001)
...
BLOCK_KEY0 (BLOCK4)
  Purpose: XTS_AES_128_KEY
    Key0 or user data                                 
   = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/- 

[KonstantinKondrashov]

This is how --virt mode works; it emulates hardware behavior. If an efuse block is read-protected, then 0 will be read from this block (and in the bin file, you will see 0). This mode is dedicated to testing the efuses without a real chip connected. The command above helps you to generate the bin efuse file for qemu.
For sure, when QEMU is running, you can connect to it and burn any eFuse as you normally do.

[j4k0xb]

Again, it isn't about reading or read protection.
The bug is that burning does not work in virtual mode. Opening qemu_efuses.bin in a hex editor showed that all BLOCK_KEY0 bits are still 0.

[KonstantinKondrashov]

It’s not a bug — it’s intended behavior. The virtual efuse mode (--virt) is a software-only simulation that mimics real efuse hardware behavior. That’s why qemu_efuses.bin still shows BLOCK_KEY0 bits as zero: efuse blocks that are read-protected, by design, are hidden in the output.

[j4k0xb]

The key should be burned regardless of read protection, no? That's how the real hardware and how qemu works. Only virtual mode has this bug.
I know it would be hidden with espefuse summary etc. That's why I'm proving it with a hex editor:

Corrupt file, no key, fails to boot:

$ espefuse.py --chip esp32s3 --do-not-confirm --debug --virt --path-efuse-file build/qemu_efuse.bin burn_key --show-sensitive-info BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY

$ xxd build/qemu_efuse.bin
00000000: 0000 0000 0000 0190 0000 3000 0000 0000  ..........0.....
00000010: 0000 0000 0000 0028 0000 0000 0000 0000  .......(........
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 5aa5 0000 0000 0000 0000 0000 0000  ..Z.............
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0400 0000 0000 0001  ................
000001d0: 0080 0100 4ebe ee5b 75c2 c852 1973 1ec4  ....N..[u..R.s..
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

$ qemu-system-xtensa -nographic \
                    -M esp32s3 \
                    -drive file=build/qemu_flash.bin,if=mtd,format=raw \
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32s3.efuse,property=drive,value=efuse \
                    -serial mon:stdio
Adding SPI flash device
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x4 (SPI_FLASH_BOOT)
invalid header: 0x48abc703

Correct file, contains whole key at offset 0x70, boots:

$  espefuse.py --chip esp32s3 --do-not-confirm --debug --port socket://localhost:4444 burn_key --show-sensitive-info BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY

$ xxd build/qemu_efuse.bin
00000000: 0001 8000 0100 0000 0000 0004 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 39ff 18c0 9426 188f f7ae 3a7f fc1b 7c83  9....&....:...|.
00000080: be7e 2a84 a602 dd83 ae2e f7c8 d113 4846  .~*...........HF
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000220: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000240: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000250: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000260: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000270: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000280: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000290: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000002f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000300: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000310: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000320: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000330: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000340: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000350: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000360: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000370: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000380: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000390: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

$ qemu-system-xtensa -nographic \
                    -M esp32s3 \
                    -drive file=build/qemu_flash.bin,if=mtd,format=raw \
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32s3.efuse,property=drive,value=efuse \
                    -serial mon:stdio
Adding SPI flash device
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x4 (SPI_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2980,len:0x3478
load:0x403c8700,len:0x4
load:0x403c8704,len:0xd24
load:0x403cb700,len:0x5484
entry 0x403c8928
I (67) boot: ESP-IDF v5.4.2 2nd stage bootloader
...
I (482) flash_encrypt: Using pre-loaded flash encryption key in efuse

[KonstantinKondrashov]

#1099 (comment)

--path-efuse-file build/internal_efuse_tool_file.bin does not fit the same structure as qemu expects. Do not use this file for QEMU. It has the hardware register structure, while QEMU needs only efuse blocks.

[j4k0xb]

Ok the format differences make sense now, thanks for the clarification.

espefuse.py --chip esp32s3 --do-not-confirm --virt \
  burn_key --no-read-protect BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY \
  dump --format joint --file_name build/qemu_efuse.bin

Gets loaded by qemu fine and contains the key. However, the 2nd stage bootloader requires the key to be read/write-protected: https://github.com/espressif/esp-idf/blob/5b11d5b26a8bf151fc6bac400158859eedd413bc/components/bootloader_support/src/flash_encryption/flash_encrypt.c#L207-L211

E (438) flash_encrypt: Invalid key state, check read&write protection for key and keypurpose(if exists)
I (440) efuse: Batch mode of writing fields is cancelled
E (441) boot: Initialization of Flash Encryption key failed (259)

And as said earlier, without --no-read-protect the key isn't saved for some reason.

If an efuse block is read-protected, then 0 will be read from this block

Based on my tests, dump reads it without problems from the virtual file even if read-protected.
This creates the expected qemu_efuse.bin:

# this only saves KEY_PURPOSE_0=XTS_AES_128_KEY (R/-), BLOCK_KEY0=0000...00000 (-/-)
espefuse.py --chip esp32s3 --do-not-confirm --virt --path-efuse-file virt_efuse.bin \
  burn_key --debug BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY

# workaround to actually write to BLOCK_KEY0
dd if=flash_encryption_key.bin of=virt_efuse.bin bs=1 seek=324 conv=notrunc

# convert to format that can be used by qemu
espefuse.py --chip esp32s3 --virt --path-efuse-file virt_efuse.bin \
  dump --format joint --file_name build/qemu_efuse.bin

rm virt_efuse.bin

Back to the original issue: if virtual mode persisted read-protected efuses (even though they're not logged to the terminal), it would be possible to achieve the same result with a single command:

espefuse.py --chip esp32s3 --do-not-confirm --virt \
  burn_key BLOCK_KEY0 flash_encryption_key.bin XTS_AES_128_KEY \
  dump --format joint --file_name build/qemu_efuse.bin

[KonstantinKondrashov]

I will attempt to introduce an additional flag for virt mode to ignore read protections in EmulateEfuseController.
The new flag has to block calling check_rd_protection_area (EmulateEfuseController->handle_writing_event->check_rd_protection_area).