The blake2 tests fail. I don't think they ever passed, but until 1-August they were skipped in CI. [somers@fbsd12 /usr/tests/sys/opencrypto]$ kyua test blake2_test:blake2b_vectors -> failed: /usr/home/somers/freebsd/base/head/tests/sys/opencrypto/blake2_test.c:108: alg 29 keylen 64, errno=22 (Invalid argument) [0.002s] blake2_test:blake2b_vectors_x86 -> passed [0.003s] blake2_test:blake2s_vectors -> failed: /usr/home/somers/freebsd/base/head/tests/sys/opencrypto/blake2_test.c:108: alg 30 keylen 32, errno=22 (Invalid argument) [0.002s] blake2_test:blake2s_vectors_x86 -> passed [0.003s] runtests:main -> skipped: Requires root privileges [0.001s] Results file id is usr_tests_sys_opencrypto.20180816-152350-234384 Results saved to /home/somers/.kyua/store/results.usr_tests_sys_opencrypto.20180816-152350-234384.db 3/5 passed (2 failed)
Um, they all passed when they were committed and still pass on my system. What's different about the CI environment?
Is the CI environment just running too old of a kernel?
I don't know what's different between the CI system (and mine) versus yours. If it helps, this is the portion of the ktrace output that returns EINVAL: 46212 blake2_test CALL openat(AT_FDCWD,0x200430,0x2<O_RDWR>) 46212 blake2_test NAMI "/dev/crypto" 46212 blake2_test RET openat 3 46212 blake2_test CALL ioctl(0x3,CRIOGET,0x7fffffffd5b0) 46212 blake2_test RET ioctl 0 46212 blake2_test CALL close(0x3) 46212 blake2_test RET close 0 46212 blake2_test CALL ioctl(0x4,CIOCGSESSION2,0x7fffffffd5b0) 46212 blake2_test RET ioctl -1 errno 22 Invalid argument
This most certainly is reproducible. It reproduces on every CI build (the kernel is rebuilt for each one), and it reproduces on my VM too.
(In reply to Alan Somers from comment #3) Nah, I already had that much from the test line number, unfortunately. What can you tell me about your VM/system? Is it running a recent CURRENT? What revision? What architecture? Would it be possible to re-test on a build with CRYPTDEB toggled on and provide dmesg output? Much appreciated.
An amd64 BHyve VM running a GENERIC kernel built from r337735. Dtrace identifies the error as coming from cryptodev.c line 590. It also shows that crid == 0x2000000. So the test is requesting a software crypto device/driver, but that's not allowed. And indeed, setting kern.cryptodevallowsoft=1 fixes the failure. I suppose the correct fix would either be to set that sysctl in the test itself, or to skip the test if it's not set. But I don't know which. Do you?
(In reply to Alan Somers from comment #6) Six one, half a dozen the other. Either option will cause the test to be skipped on CI, since setting the sysctl requires root.
The test is broken; CI is just a messenger. We need to fix the test independently of CI's configuration. The question is: is this testcase explicitly trying to test a software device? Or is this some kind of situation where it's really looking for hardware, but falling back to software? Would the coverage of any other test cases be negatively affected if we enabled the sysctl?
It is explicitly trying to test the software implementation (if available) as well as the hardware implementation (if available). Currently "available" is conditioned on the presence of the module (i.e., "cryptosoft"). I don't know that other test cases would be affected if the sysctl is enabled. Nothing *should* change, since theoretically all drivers implementing a primitive implement it correctly, and software implementations are more likely to accept a broader range of inputs than hardware implementations. But I don't really know.
I guess the other question is, why would anybody ever want kern.cryptodevallowsoft=0 ? What would a user gain by disallowing software crypto?
(In reply to Alan Somers from comment #10) I really don't know :-). I think the idea is to prevent naive userspace programs from assuming /dev/crypto will accelerate their algorithms when a software implementation in kernel is unlikely to. But generally they should avoid that by asking for a HARDWARE crid. Exposing cryptosoft via dev/crypto makes a lot of sense for testing, though.
A commit references this bug: Author: asomers Date: Thu Aug 16 23:49:56 UTC 2018 New revision: 337933 URL: https://svnweb.freebsd.org/changeset/base/337933 Log: Fix sys/opencrypto/blake2_test when kern.cryptodevallowsoft=0 Two of these testcases require software crypto to be enabled. Curiously, it isn't by default. PR: 230671 Reported by: Jenkins Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D16755 Changes: head/tests/freebsd_test_suite/macros.h head/tests/sys/opencrypto/blake2_test.c
Thanks for fixing this! Changing assignee to you (usually we set it to match whoever fixed the PR, as far as I know).
I'm not sure you'll have to MFC this anywhere -- I added blake2 fairly recently and I didn't MFC it.
Okee dokee. When it comes up for MFC I'll ignore it. I usually MFC almost all of my stuff, so I just sort of fill in that line by default.