Conversation
The SoC has a non-secure TRNG at 0xfe378000 that nothing was using. RngLib resolved to BaseRngLibTimerLib, which derives numbers from the performance counter and reports gEdkiiRngAlgorithmUnSafe -- and that is what TlsDxe, Hash2DxeCrypto and IScsiDxe link against, so HTTPS boot was seeded from a timer. EFI_RNG_PROTOCOL was unaffected: RngDxe sorts an unsafe RngLib algorithm to the end of its list and serves Raw from TF-A's SMCCC TRNG first, so the entropy handed to the OS was already hardware. Add a RngLib instance for the block. It cannot be DxeRngLib -- that depexes on gEfiRngProtocolGuid, which RngDxe itself produces while also consuming RngLib, so RngDxe would wait on a protocol only it can install and never dispatch. The block is TRNG v1, matching mainline's rockchip,rk3588-rng -- not the RK356x RNG, which sits in the crypto v2 unit with an unrelated layout. The version register is checked before anything else is touched and the library falls back to the performance counter if it does not answer, so a board where the block is unreachable behaves as it did before. GetRngGuid reports gRk3588RngAlgorithmTrngV1Guid, a GUID of its own, rather than gEfiRngAlgorithmRaw: RngDxe registers each source it can serve separately, and reusing Raw -- already taken by the SMCCC TRNG -- would advertise the same algorithm twice. EFI_RNG_PROTOCOL therefore gains a second entry and this block becomes its default, ahead of the SMCCC TRNG. On fallback the library reports UnSafe and RngDxe demotes it as before. Enabled by default for RK3588 via RK3588_TRNG_ENABLE. Verified on a PowerStation 6 over serial: the probe reports "TRNG v1 ready" under both RngDxe and TlsDxe, and RngDxe's unsafe-algorithm warning does not appear, so the block is in use rather than falling back to the timer.
Collaborator
Right, but we don't have to link RngDxe against DxeRngLib. It can remain the BaseRngLibTimerLib instance, and for which overrides the timer-based instance just for that driver type. So we don't actually need a second driver here. |
Collaborator
Contributor
Author
|
Obsoleted by be4d361 — that covers the |
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.
The SoC has a non-secure TRNG at
0xfe378000that nothing was using. RngLibresolved to
BaseRngLibTimerLib— the performance counter, reportinggEdkiiRngAlgorithmUnSafe— and that's what TlsDxe, Hash2DxeCrypto andIScsiDxe link against, so HTTPS boot was seeded from a timer.
EFI_RNG_PROTOCOLwas unaffected: RngDxe sorts an unsafe RngLib algorithm tothe end of its list and serves Raw from TF-A's SMCCC TRNG first.
It has to be a RngLib instance, not
DxeRngLib— that depexes ongEfiRngProtocolGuid, which RngDxe both produces and consumes RngLib for, soRngDxe would wait on a protocol only it can install and never dispatch.
GetRngGuidreportsgRk3588RngAlgorithmTrngV1Guidrather thangEfiRngAlgorithmRaw, which is already taken by the SMCCC TRNG and wouldadvertise the same algorithm twice.
EFI_RNG_PROTOCOLgains a second entryand this block becomes its default. On fallback the library reports UnSafe
and RngDxe demotes it as before.
The version register is checked before anything else is touched, falling back
to the performance counter if it doesn't answer, so a board where the block
is unreachable behaves as it did before.
Verified on a PowerStation 6 over serial:
Rk3588Rng: TRNG v1 ready.underboth RngDxe and TlsDxe, with RngDxe's unsafe-algorithm warning absent.
Enabled by default via
RK3588_TRNG_ENABLE.