Skip to content

core: hwrng: add a dummy hwrng for test purposes on qemu. #7562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
+19 −0
Closed

core: hwrng: add a dummy hwrng for test purposes on qemu. #7562

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions core/crypto.mk
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,12 @@ endif
# Otherwise, you need to implement hw_get_random_bytes() for your platform
CFG_WITH_SOFTWARE_PRNG ?= y

# dummy hwrng
# this config adds a dummy hwrng to be used
# with qemu to expose a hwrng interface to
# bootloaders or other non secure firmwares
CFG_WITH_DUMMY_HWRNG ?= n

# Define the maximum size, in bits, for big numbers in the TEE core (privileged
# layer).
# This value is an upper limit for the key size in any cryptographic algorithm
Expand Down
13 changes: 13 additions & 0 deletions core/pta/hwrng.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,19 @@
/* This PTA only works with hardware random number generators */
static_assert(!IS_ENABLED(CFG_WITH_SOFTWARE_PRNG));

#if defined(CFG_WITH_DUMMY_HWRNG)
TEE_Result hw_get_random_bytes(void *buf, size_t len)
{
uint8_t *b = buf;
for (size_t i = 0; i < len; i++) {
uint64_t cnt = read_cntpct(); // read QEMU virtual timer
b[i] = (uint8_t)(cnt & 0xFF);
}

return TEE_SUCCESS;
}
#endif

Copy link
Contributor

@jforissier jforissier Oct 7, 2025

Choose a reason for hiding this comment

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

The PTA is not the best place for this function. I'd rather have it as a driver in core/drivers/dummy_cntpct_rng.c guarded by CFG_DUMMY_CNTPCT_RNG.

But more fundamentally: how is this better than the software PRNG that OP-TEE uses by default on QEMU? (CFG_WITH_SOFTWARE_PRNG=y). If you want better randomness on QEMU then I would recommend implementing a RNG based on the RNDR instruction (which is supported by QEMU with -cpu max). That would also benefit real hardware (ARMv8.5+).

Copy link
Author

@anischali anischali Oct 13, 2025

Choose a reason for hiding this comment

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

Hello, thanks for taking the time, I will give a try for soft prng but my need is to see how the bootloader interfaces with hwrng, in my case I use arm64 qemu to emulate TF-A >> optee >> barebox and the a kernel. so barebox implements hwrng uuid so I added this for test with qemu and I thought it would interessting to send main line for educational purposes. but the best would be to implement a virtio to benefit from what qemu exposes. there is much more work to do for that. anyway maybe it is not so relevent to have the feature in ML

static TEE_Result rng_get_entropy(uint32_t types,
TEE_Param params[TEE_NUM_PARAMS])
{
Expand Down
Loading