hw_unique_key: Create read Kconfig option #11976
Conversation
mswarowsky
requested review from
frkv,
Vge0rge,
vili-nordic,
joerchan,
SebastianBoe and
carlescufi
as code owners
github-actions
bot
added
changelog-entry-required
mswarowsky
removed
the
changelog-entry-required
Test specificationCI/Jenkins/NRF
CI/Jenkins/integration
Detailed information of selected test modules Note: This message is automatically posted and updated by the CI |
|
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publishing GitHub Action. |
github-actions
bot
added
the
changelog-entry-required
mswarowsky
force-pushed
the
hw_key_kconfig
branch
from
05d497b
to
096752a
Compare
lib/hw_unique_key/Kconfig
Outdated
| Use the Hardware Unique Key (HUK) in read access to derive new keys. | ||
| It will require an immutable bootloader with the CONFIG_HW_UNIQUE_KEY_LOAD | ||
| option set on devices without a KMU. | ||
| Note that the key has to be written before. |
There was a problem hiding this comment.
Btw, the key has to be written before what?
There was a problem hiding this comment.
before it can be read.
Is that enough or do you think that requires more details
There was a problem hiding this comment.
I would maybe add more details. Is that something that user has to make sure that it's done? And how. Maybe reference to or mention of a function/option/procedure that is used, if any.
There was a problem hiding this comment.
Oh was not aware that we include procedure descriptions in Kconfigs,
I added a reference to the Kconfigs used for that, I feel describing the whole process here is a bit too much.
There was a problem hiding this comment.
Yeah, no need to describe the entire process.
It just needed some more info, because writing just simply that the key has to be written before it is read is kind of obvious and does not give that much of a useful info.
But writing that the key has to be written by XX before it can be read, or XX has to have completed and written the key before it can be read gives a clear instruction on what users should be looking out for.
Giving these references is useful I think, so if you are happy now, then I am as well :)
There was a problem hiding this comment.
Yeah makes sense, but I think the reference to the Kconfig that is needed for writing should be fine now
mswarowsky
force-pushed
the
hw_key_kconfig
branch
from
7463c3a
to
e7549d5
Compare
mswarowsky
force-pushed
the
hw_key_kconfig
branch
from
e7549d5
to
5dcc106
Compare
mswarowsky
force-pushed
the
hw_key_kconfig
branch
2 times, most recently
from
dceb8fd
to
aa1ddb8
Compare
mswarowsky
force-pushed
the
hw_key_kconfig
branch
4 times, most recently
from
67c77da
to
59c6b72
Compare
On nRF52840 to use the HUK the immustable bootloader is needed. By adding a new Kconfig option that should be used the key is just read but not written we ensure during build time that the images includes the immutable bootloader. Signed-off-by: Markus Swarowsky <markus.swarowsky@nordicsemi.no>
mswarowsky
force-pushed
the
hw_key_kconfig
branch
from
59c6b72
to
d599cfb
Compare
|
Turned out we will run in cyclic Kconfig dependencies, So I give on on what was supposed to be a small fix... |
On nRF52840 to use the HUK the immustable bootloader is needed. By adding a new Kconfig option that should be used the key is just read but not written we ensure during build time that the images includes the immutable bootloader.