tools: verilate: improve invalid file detection and reporting
#228
Conversation
As Verilator is run from a temporary directory rather than the one which the script is launched from: 1. when an alternative artifact path is specified, it should be stored as an absolute path, 2. RAM/ROM/eFlash/OTP file paths should be stored as absolute paths Beware that the memory initializer functions seem to silently ignore any invalid file path. Signed-off-by: Emmanuel Blot <eblot@rivosinc.com>
rivos-eblot
force-pushed
the
dev/ebl/vtor_abs_path
branch
from
84e2951 to
45974a8
Compare
|
It seems that |
There was a problem hiding this comment.
LGTM.
It seems that //sw/device/tests/crypto:symmetric_keygen_functest_sim_qemu_sival_rom_ext keeps failing
This test is failing because it checks for the quality of the randomness, which is sometimes not good enough in the QEMU model. This passes consistently for me locally on the latest earlgrey_1.0.0/ot-9.2.0 checkouts, but given it is failing in CI feel free to ignore the failure (and ideally, mark it flaky in the tests file).
python/qemu/ot/verilator/executer.py
Outdated
| # for some reason, Verilator ouput log message to stdout | ||
| # not stderr |
There was a problem hiding this comment.
| # for some reason, Verilator ouput log message to stdout | |
| # not stderr | |
| # for some reason, Verilator outputs log messages to stdout, | |
| # not stderr |
Oh ok, thanks for the details. There is a feature (I need to dig into the code as I wrote it but already forgot about it) in the entropy stack that deals with something that could be worth to check: I forgot the context, but as it may (too much) time to get proper entropy in QEMU, this was causing trouble with some tests or some apps. Therefore, there is a feature that triggers in if no entropy cannot be made available fast enough at boot that bypasses the full entropy stack and delivers low-quality entropy. However I think this was only triggered at boot up stage, not at runtime. Maybe the feature is bugged. Although I guess that if entropy quality measurement is done within the entropy_src, several registers (health tests, etc.) are not implemented at all. |
rivos-eblot
force-pushed
the
dev/ebl/vtor_abs_path
branch
from
45974a8 to
7745fb2
Compare
… the logger
OpenTitan Verilator wrapper silently ignores:
1. Any unknown argument from the command line
2. Invalid file paths to initialize memory device (if a non-existing file is submitted,
simulation begins anyway with an unexpected outcome)
However invalid path are reported as a mere warning on the standard output stream,
from the $readmemh Verilog function. Add a special filter to extract Verilator message
out of the verbose Verilator wrapper output so the issue can be signaled back to the
user.
Also disable CLI command line simplification when debug mode is enabled, to track
the exact file path of each initialized file in this mode.
Side note: OT wrapper relies on the file extension to figure out the type of a file,
not its content.
Signed-off-by: Emmanuel Blot <eblot@rivosinc.com>
rivos-eblot
force-pushed
the
dev/ebl/vtor_abs_path
branch
from
7745fb2 to
d496957
Compare
Are you referring to e.g. |
Yes, this one, you better know my code than I do :)
Maybe we need to change this to a trace then. It was mostly informative. I initially used an Is the test reporting bad entropy using some of the advance entropy_src monitoring (and unimplemented) registers or is the test checking entropy quality on its own? As the entropy stack implements all the complex entropy processing stages, I hope it's only the monitoring registers that are not implemented. Sorry about this full off-topic thread. |
On its own, as part of the test it generates symmetric keys and then does a basic statistical check by counting the number of 0 and 1 bits in the keyblob. If they aren't roughly similar, the test fails. It does this for AES, KMAC and HMAC. I guess we might expect this to sometimes because of the lack of masking with entropy in e.g. KMAC. (sorry, I should have been more clear it was the randomness in the generated keys and not necessarily the entropy stack itself). |
Ok, much clearer. If I get it right, you are referring to QEMU setting a half of the key share to 0, while setting the other half to the actual keyshare value(?). Could we simply "randomize" the first half with a random number and XOR-ing the second half with the first half? |
2 participants
No description provided.