Repository navigation
arch/arm64/imx9: add key store, signing and persistence to the ELE - #20343
Merged
Merged
Conversation
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 24, 2026 12:00
9b7d7af to
8ab1820
Compare
royzah
marked this pull request as draft
September 24, 2026 12:02
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 24, 2026 12:06
8ab1820 to
26a6fb8
Compare
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 24, 2026 16:14
26a6fb8 to
5cec1bc
Compare
royzah
marked this pull request as ready for review
September 24, 2026 16:15
xiaoxiang781216
previously approved these changes
Sep 25, 2026
Contributor
Author
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 27, 2026 07:09
5cec1bc to
e3a6f6d
Compare
Contributor
Author
|
Pushed two fixes found on hardware, squashed in:
nxstyle clean. Sorry for the re-review @xiaoxiang781216 |
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 27, 2026 07:13
e3a6f6d to
7ce439f
Compare
xiaoxiang781216
previously approved these changes
Sep 27, 2026
Contributor
Author
|
@acassis @pussuw @tkaratapanis if any of you has ten minutes, extra eyes very welcome |
jlaitine
reviewed
Sep 27, 2026
jlaitine
left a comment
Contributor
There was a problem hiding this comment.
I added just a few comments, nice work!
I'd re-check the cache operations. I made some quick notes about those, but didn't have time to really think twice. Please just re-check those points!
The EdgeLock Enclave offers a key store the mailbox driver did not reach. A key generated in there is permitted one algorithm and one usage, and export can be withheld, so the private half has no command that returns it. Adds the session, key store and key management services, key generation, signing by handle, and the storage exchange that makes a key store outlive a boot. Storage runs the other way round from every other command: the enclave asks the host to write its key store down and to give it back, and those requests arrive while a command of this side's is still outstanding, so the reply tag is what tells them apart. Two things a port has to know and neither reference nor header says. Key store commands carry a trailing crc, the exclusive or of every word including the header, without which the enclave answers rating 0xb9. And a persistent key lifetime is a statement of intent: the strict flag on key generation is what writes the key to the store, and without it a store exported around the key comes back without it. Every mailbox wait is bounded. An enclave that stops answering must not take the calling thread with it, and a reply buffer is a kilobyte, which does not belong on the stack of whatever task asked for a signature. Tested on an i.MX93: a P-256 key generated in the enclave, signing a digest whose signature verifies against the returned public half on a host, and still doing so after the board has been powered off. Signed-off-by: Royyan Zahir <royzah@gmail.com>
royzah
force-pushed
the
upstream-ele-keystore
branch
from
September 27, 2026 18:22
7ce439f to
91c26c2
Compare
royzah
added a commit
to tiiuae/nuttx
that referenced
this pull request
Sep 27, 2026
Review on apache#20343: clean what the enclave reads, poll the mailbox every 1us, and sign into a driver-owned line so callers need no aligned buffer.
royzah
added a commit
to tiiuae/px4-firmware
that referenced
this pull request
Sep 27, 2026
Contributor
|
Thanks @royzah, looks nice |
jlaitine
approved these changes
Sep 27, 2026
jerpelea
approved these changes
Sep 28, 2026
Contributor
Author
|
@xiaoxiang781216 and @acassis can you take another look ? |
xiaoxiang781216
approved these changes
Sep 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The i.MX9 ELE driver reaches the mailbox but not the key store the enclave offers. This adds sessions, key stores, key management, key generation, signing by handle, and the storage exchange that lets a key store outlive a boot.
A key generated in there is permitted one algorithm and one usage, and export can be withheld, so the private half has no command that returns it.
Storage runs the opposite way to every other command: the enclave asks the host to write its key store down and to give it back, and those requests arrive while a command of this side's is still outstanding. The reply tag is what tells a question from an answer.
Two things neither the reference implementation nor the headers say, each of which looks from outside like "this firmware has no key store":
0xb9.0x03.Mailbox waits are now bounded in both directions, and the kilobyte reply buffer no longer sits on the caller's stack.
Impact
i.MX9 only, additive. No Kconfig, no init-time behaviour, nothing enabled by default. Boards that do not call the new functions are unaffected. The command payload layouts move to file scope as named types.
Testing
On an i.MX93 Cortex-A55 board, NuttX 12.11.0, kernel build. A P-256 key generated in the enclave, signing
sha256(""):Power cycled, then repeated. The key store is restored from the pieces the enclave exported, the public half is byte-identical, and a fresh signature verifies against it. ECDSA is randomised, so verification is the test, not comparison.
tools/checkpatch.sh -fpasses on all three files.