Skip to content

[keymgr_dpe, sw] Support metadata register in various driver - #31356

Open
rroth-lowrisc wants to merge 5 commits into
lowRISC:masterfrom
rroth-lowrisc:keymgr_dpe_feat_read_metadata_sw
Open

rroth-lowrisc wants to merge 5 commits into
lowRISC:masterfrom
rroth-lowrisc:keymgr_dpe_feat_read_metadata_sw

Conversation

@rroth-lowrisc

Copy link
Copy Markdown
Contributor

This PR introduces the required driver modification for #31228. It implements the read metadata functionality in silicon_creator / cryptolib / dif libraries. To test the feature the keymgr_dpe_functest is extended to verify the boot_stage of the derived DPE context.

This PR depends on:

Only the last 5 commits are relevant for this PR.

@gautschimi gautschimi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only minor comments. What is the reason for having two versions of keymgr_dpe.c/h?

Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.h Outdated
Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.h
@rroth-lowrisc
rroth-lowrisc force-pushed the keymgr_dpe_feat_read_metadata_sw branch from fad7df1 to fd10c1b Compare September 29, 2026 09:54
@rroth-lowrisc
rroth-lowrisc marked this pull request as ready for review October 5, 2026 07:47
@rroth-lowrisc
rroth-lowrisc requested review from a team as code owners October 5, 2026 07:47
@rroth-lowrisc
rroth-lowrisc requested review from a team, KinzaQamar, jwnrt and moidx and removed request for a team, KinzaQamar, jwnrt and moidx October 5, 2026 07:47
@rroth-lowrisc
rroth-lowrisc force-pushed the keymgr_dpe_feat_read_metadata_sw branch 2 times, most recently from 75f56fa to 77f45d8 Compare October 5, 2026 15:46

@gautschimi gautschimi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR. Looks mostly good. only minor comments:

  1. unittests

There are no unit tests, and some new code has no callers.

dif_keymgr_dpe_unittest.cc and silicon_creator/lib/drivers/keymgr_dpe_unittest.cc both exist, but neither gets a test for the new functions.

keymgr_dpe_testutils_check_metadata() and the cryptolib keymgr_dpe_get_metadata() aren't called anywhere in this PR. Is there already a followup PR that uses them? Even if not, it's mostly debug functionality. so probably not required.

  1. bazel deps

keymgr_dpe_functest may be missing a Bazel dependency. It now includes silicon_creator/lib/manifest.h and manifest_def.h, but the PR doesn't touch sw/device/silicon_creator/lib/drivers/BUILD.

It probably builds because ottf_main pulls in test_framework_manifest_def indirectly.
Adding a direct dependency on //sw/device/silicon_creator/lib:manifest would be cleaner.

  1. Nit: the types differ between layers.

The DIF uses uint32_t for boot_stage and valid.
The cryptolib uses a bool plus its own enum.
silicon_creator uses its own enum with uint32_t valid.

Could we just define this boot_stage enum once? Aligns with an earlier comment of mine.

I don't fully understand why we have two versions of keymgr_dpe.c/h @nasahlpa is that intended?

Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.c
@rroth-lowrisc

rroth-lowrisc commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor Author

Thanks for this PR. Looks mostly good. only minor comments:

1. unittests

There are no unit tests, and some new code has no callers.

dif_keymgr_dpe_unittest.cc and silicon_creator/lib/drivers/keymgr_dpe_unittest.cc both exist, but neither gets a test for the new functions.

keymgr_dpe_testutils_check_metadata() and the cryptolib keymgr_dpe_get_metadata() aren't called anywhere in this PR. Is there already a followup PR that uses them? Even if not, it's mostly debug functionality. so probably not required.

2. bazel deps

keymgr_dpe_functest may be missing a Bazel dependency. It now includes silicon_creator/lib/manifest.h and manifest_def.h, but the PR doesn't touch sw/device/silicon_creator/lib/drivers/BUILD.

It probably builds because ottf_main pulls in test_framework_manifest_def indirectly. Adding a direct dependency on //sw/device/silicon_creator/lib:manifest would be cleaner.

3. Nit: the types differ between layers.

The DIF uses uint32_t for boot_stage and valid. The cryptolib uses a bool plus its own enum. silicon_creator uses its own enum with uint32_t valid.

Could we just define this boot_stage enum once? Aligns with an earlier comment of mine.

I don't fully understand why we have two versions of keymgr_dpe.c/h @nasahlpa is that intended?

Thanks for the review @gautschimi

  1. I extended silicon_creator/lib/drivers/keymgr_dpe_unittest.cc to check the new functions. Currently the dif_keymgr_dpe_unittest.cc is empty, so this will be fixed in a follow-up PR. keymgr_dpe_testutils_check_metadata() and the cryptolib keymgr_dpe_get_metadata() will be used in [keymgr_dpe, rom/rom_ext] Verify boot_stage of UDS / CDI_0 / CDI_1 DPE context #31357
  2. Fixed the missing dependency
  3. I had an offline disscussion with @nasahlpa: silicon_creator is fixed for ROM during tape-out and will not be changed afterwards. The cryptolib will evolve after tape-out, so nothing can be shared between the two.
  4. I will change the silicon driver to use bool for the valid too.

@nasahlpa
nasahlpa requested a review from siemen11 October 6, 2026 08:11
@rroth-lowrisc
rroth-lowrisc force-pushed the keymgr_dpe_feat_read_metadata_sw branch from 77f45d8 to 8486540 Compare October 6, 2026 08:24

@gautschimi gautschimi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! Thanks for the additional unittests, clarifications and the enum alignment.

All my comments have been addressed. Approving this PR.

@rroth-lowrisc
rroth-lowrisc force-pushed the keymgr_dpe_feat_read_metadata_sw branch from 8486540 to 4cf558e Compare October 6, 2026 08:31

@andrea-caforio andrea-caforio left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rroth-lowrisc. Some questions and remarks from my side.

Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.c
Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.c
Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.h
Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.h Outdated
Comment thread sw/device/lib/crypto/drivers/keymgr_dpe.h Outdated
Comment thread sw/device/lib/dif/dif_keymgr_dpe.c Outdated
Comment on lines +312 to +318
ptrdiff_t offset_low = (ptrdiff_t)(KEYMGR_DPE_METADATA_LOW_0_REG_OFFSET +
slot * sizeof(uint32_t));
ptrdiff_t offset_high = (ptrdiff_t)(KEYMGR_DPE_METADATA_HIGH_0_REG_OFFSET +
slot * sizeof(uint32_t));

metadata->max_key_version =
mmio_region_read32(keymgr_dpe->base_addr, offset_low);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't you do it like in the driver function to get the register addresses?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the intermediate variables offset_low and offset_high. However, the dif doesn't have access to the abs_mmio_read32() function which uses an absolute uint32_t address.

* Checks that a keymgr_dpe HW slot holds a valid DPE context with the expected
* maximum key version, boot stage and slot policy.
*/
rom_error_t sc_keymgr_dpe_check_metadata(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of a redundant function to be honest. If you really need a test then do the verification step by in the test itself.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is actually the main feature. The goal of this feature is to verify if a derivation was properly done by checking all the metadata after the derivation.

IMO it doesn't make sense to implement this function multiple times.

One example for this function can be seen in #31357. I'm verifying if the derivation in the ROM code was successfully (bcf6bca).

…tadata

Read the max key version, validity, boot stage and policy of one slot.

Signed-off-by: Raphael Roth <rroth@lowrisc.org>
Check that a slot holds a valid DPE context with the expected max key
version, boot stage and policy, to confirm a derivation happened.

Signed-off-by: Raphael Roth <rroth@lowrisc.org>
Add `sc_keymgr_dpe_get_metadata()` and `sc_keymgr_dpe_check_metadata()`,
both hardened against FI on the slot index and the checked fields.

Signed-off-by: Raphael Roth <rroth@lowrisc.org>
Verify the DPE context after each advance operation with
`sc_keymgr_dpe_boot_stage_check()`. This ensures that the
derivation was done correctly.

Signed-off-by: Raphael Roth <rroth@lowrisc.org>
Read the max key version, validity, boot stage and policy of one slot.
Out-of-range slots return `OTCRYPTO_BAD_ARGS` behind a hardened check.

Signed-off-by: Raphael Roth <rroth@lowrisc.org>
@rroth-lowrisc
rroth-lowrisc force-pushed the keymgr_dpe_feat_read_metadata_sw branch from 4cf558e to adfbe42 Compare October 6, 2026 14:00
@rroth-lowrisc
rroth-lowrisc requested a review from a team as a code owner October 6, 2026 14:00
@rroth-lowrisc
rroth-lowrisc requested review from sasdf and removed request for a team and sasdf October 6, 2026 14:00
@rroth-lowrisc

Copy link
Copy Markdown
Contributor Author

Thanks @andrea-caforio for the review

I changed the code accordingly and answered your questions

@andrea-caforio andrea-caforio left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rroth-lowrisc.

@rroth-lowrisc rroth-lowrisc added the CI:Rerun Rerun failed CI jobs label Oct 7, 2026
@github-actions github-actions Bot removed the CI:Rerun Rerun failed CI jobs label Oct 7, 2026
@rroth-lowrisc rroth-lowrisc added the CI:Rerun Rerun failed CI jobs label Oct 8, 2026
@github-actions github-actions Bot removed the CI:Rerun Rerun failed CI jobs label Oct 8, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants