Backport 4.1: ssl_fork_server RNG testing - #10858
Open
gilles-peskine-arm wants to merge 13 commits into
Open
Conversation
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
`ssl_fork_server` reseeds its RNG, so in a build with a nonvolatile seed, it re-reads the seed file midway. If the client also rewrites the seed file while the server is running, that causes the test conditions to not reflect real-world conditions for the server. Fix this by running `ssl_fork_server` in its own directory when we're asserting properties of the random generator. This was a relatively easy way to separate the client seed file from the server seed file, since the seed file name `"seedfile"` is not configurable at runtime. This mostly matters for builds with no actual entropy source, only an NV seed. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Assert that when two clients connect to ssl_fork_server, they see different random values from the server. This validates that each child process has its own random generator state. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
gilles-peskine-arm
added
needs-ci
github-project-automation
Bot
moved this to In Development
in Roadmap pull requests (new board)
6 tasks
Assert that when two clients connect to ssl_fork_server, they see different ephemeral public keys from the server. This validates that each child process has its own random generator state. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Run some of `ssl-opt.sh` on builds with only an NV seed as the entropy source. There isn't much impact outside of the crypto unit tests, but do test that it works in a "real" program. In particular, run `ssl_fork_server` which has a peculiar challenge since its RNG state is replicated. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
…ient random values Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a bug introduced in "Fix temporary directory left behind on normal exit" that caused the exit code of `ssl-opt.sh` to be 1 on success. Also, when exiting on a trapped signal, re-raise the signal rather than exiting with status 1. Also, on failure, where we report the number of failures through the exit code, clamp the exit code to 125 to avoid confusion with standard values. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
gilles-peskine-arm
force-pushed
the
ssl_fork_server-rng-test-4.1
branch
from
August 5, 2026 17:25
5bbac53 to
1e55066
Compare
gilles-peskine-arm
added
needs-review
6 tasks
bensze01
previously approved these changes
Aug 7, 2026
bensze01
left a comment
bensze01
left a comment
Contributor
There was a problem hiding this comment.
LGTM - faithful forward port minus the differences discussed in the description.
bjwtaylor
reviewed
Aug 12, 2026
bjwtaylor
left a comment
bjwtaylor
left a comment
Contributor
There was a problem hiding this comment.
One small suggestion, that I would be interested in what you think to.
| server_with_own_seedfile () { | ||
| set -eu | ||
| test -d "$subdirectory_for_server_seedfile" || mkdir "$subdirectory_for_server_seedfile" | ||
| test -s "$subdirectory_for_server_seedfile/seedfile" || cp seedfile "$subdirectory_for_server_seedfile" |
Contributor
There was a problem hiding this comment.
This unconditional copy requires provision of the seedfile prior to running tests/ssl-opt.sh. Currently this seedfile is created in all.sh, which means that this then succeeds. However this will prevent the running of ssl-opt.sh without the provisioning of this file. Given that the command is a very short lived dd from urandom and as far as I can tell there are only 8 uses, is it worth moving this dd somewhere within ssl-opt. As this will make it easier to debug and maintain ssl-opt.sh?
The test case passes even if the two clients have different RNG seeds, but in that case, it doesn't do what it claims, but instead it duplicates the "2 successive clients, TLS 1.3" test case above. So run "2 successive clients with same seed, TLS 1.3" only when there is no entropy, like "2 successive clients with same seed, TLS 1.3". Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
bjwtaylor
previously approved these changes
Aug 13, 2026
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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
3 participants
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.
Test that
ssl_fork_serverhas a different RNG state in each client. Fixes #10664.Forward port of #10666. Differences:
component_test_entropy_nv_seed_onlyalready exists in crypto but we now add it to mbedtls so that we can runssl-opt.sh. Also, in 4.x, there's only one variant becauseMBEDTLS_USE_PSA_CRYPTOis always enabled.PR checklist