Add IPSec tests in tunnel mode
ClosedPublic
Actions

Authored by olivier on Nov 9 2017, 2:26 PM.

Details

Reviewers

cem
gnn
ae
kp
jmg
bz

Commits

rS326497: Add IPSec tests in tunnel mode

Summary

Some IPSec in tunnel mode allowing to test multiple IPSec configurations.
These tests are reusing the jail/vnet scripts from pf tests for generating complex network.

I've got still some questions:

How to add the case of with and without AESNI without rewriting all these tests?
And idea for adding TCP/MD5 tests?
How about merging the utils.subr that share big part with the pf tests ?

Here is as example, the current results without and with AESNI (on a head r325309):

# kldunload aesni
# kyua test -k /usr/tests/Kyuafile sys/netipsec/tunnel/
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  failed: atf-check failed; see the output of the test for details  [0.279s]
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v6  ->  failed: atf-check failed; see the output of the test for details  [2.402s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v4  ->  failed: atf-check failed; see the output of the test for details  [0.274s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v6  ->  failed: atf-check failed; see the output of the test for details  [2.399s]
sys/netipsec/tunnel/aes_gcm_128:v4  ->  passed  [0.290s]
sys/netipsec/tunnel/aes_gcm_128:v6  ->  passed  [2.408s]
sys/netipsec/tunnel/aes_gcm_256:v4  ->  passed  [0.281s]
sys/netipsec/tunnel/aes_gcm_256:v6  ->  passed  [2.296s]
sys/netipsec/tunnel/empty:v4  ->  passed  [0.282s]
sys/netipsec/tunnel/empty:v6  ->  passed  [2.410s]

Results file id is usr_tests.20171109-141000-605659
Results saved to /root/.kyua/store/results.usr_tests.20171109-141000-605659.db

6/10 passed (4 failed)

Now with AESNI module loaded:

# kldload aesni


 # kyua test -k /usr/tests/Kyuafile sys/netipsec/tunnel/
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  failed: atf-check failed; see the output of the test for details  [0.272s]
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v6  ->  failed: atf-check failed; see the output of the test for details  [2.305s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v4  ->  failed: atf-check failed; see the output of the test for details  [0.272s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v6  ->  failed: atf-check failed; see the output of the test for details  [2.395s]
sys/netipsec/tunnel/aes_gcm_128:v4  ->  passed  [0.280s]
sys/netipsec/tunnel/aes_gcm_128:v6  ->  failed: atf-check failed; see the output of the test for details  [13.593s]
sys/netipsec/tunnel/aes_gcm_256:v4  ->  passed  [0.288s]
sys/netipsec/tunnel/aes_gcm_256:v6  ->  failed: atf-check failed; see the output of the test for details  [13.927s]
sys/netipsec/tunnel/empty:v4  ->  passed  [0.285s]
sys/netipsec/tunnel/empty:v6  ->  passed  [2.403s]

Results file id is usr_tests.20171109-141055-597373
Results saved to /root/.kyua/store/results.usr_tests.20171109-141055-597373.db

4/10 passed (6 failed)

Notice the problem of current regarding HMAC keysize (D12770) and GCM behavior change with AESNI loaded.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Warnings

Severity	Location	Code	Message
Warning	tests/sys/netipsec/tunnel/aes_cbc_128_hmac_sha1.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aes_gcm_128.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aes_gcm_256.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aesni_aes_cbc_128_hmac_sha1.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aesni_aes_cbc_256_hmac_sha2_256.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aesni_aes_gcm_128.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/aesni_aes_gcm_256.sh:	CHMOD1	Invalid Executable
Warning	tests/sys/netipsec/tunnel/empty.sh:	CHMOD1	Invalid Executable

Unit

No Test Coverage

Build Status

Buildable 12813
Build 13080: arc lint + arc unit

Event Timeline

olivier created this revision.Nov 9 2017, 2:26 PM

olivier added reviewers: jmg, bz.

How to add the case of with and without AESNI without rewriting all these tests?

It should be possible to detect if AESNI is supported.
The test is probably allowed to load the module if it's unloaded again when it finished,

I think the individual tests can be abstracted a bit further, so that the test bodies become even simpler, which would reduce the burden of duplicated the tests for with/without AESNI.

How about merging the utils.subr that share big part with the pf tests ?

I think we can pull the pft_init, pft_mkepair, pft_mkjail... functions out, and present them as a utility library for VIMAGE based tests. That probably belongs in a separate review though.
We'd need to look at what would be an appropriate place (and function prefix) for that.

tests/sys/netipsec/tunnel/aes_cbc_128_hmac_sha1.sh
24	I think it's better to keep these files in the current working directory, rather than /tmp/. I believe kyua cleans those up if something goes wrong, but not the ones in /tmp.
46	These tests tend to repeat a lot of code. I'd look at trying to write an ist_test() function or similar, which takes the IPSec configuration parameters , does the init calls and actually performs the test.
tests/sys/netipsec/tunnel/utils.subr
6	I used the 'pft_' prefix as 'PF test', so perhaps it should be different here. Maybe 'ist_' for IPSec test?
13	I'm not sure this needs to be addressed before we include these tests, but this is clearly something which could be shared between this test and the pf (and possible future other tests, like ipfw), while other functions (pft_setkey for example) are much more specific to this test.
37	It would probably be more useful to just assign them to local variables here. jname=$1 af=$2 direction=$3 ...
141	Maybe just 'rm -f' ?

Oh, also: if some of the tests are known to fail we should mark them as such until the issue is fixed.
See 'atf_expect_fail'

gnn accepted this revision.Nov 13 2017, 1:29 AM

This revision is now accepted and ready to land.Nov 13 2017, 1:29 AM

Updating test scripts following kristof's advices

This revision now requires review to proceed.Nov 17 2017, 4:35 PM

Herald added a subscriber: imp. · View Herald TranscriptNov 17 2017, 4:35 PM

olivier marked 3 inline comments as done.Nov 17 2017, 4:38 PM

olivier added inline comments.

tests/sys/netipsec/tunnel/utils.subr
6	I've renamed name of modified function, but I kept name for unmodified one for easing the merging later.

New tests output following r325872 that fixed cbc key lenght:

root@lame4 # kyua test -k /usr/tests/Kyuafile sys/netipsec/tunnel/
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  passed  [0.265s]
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v6  ->  passed  [2.400s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v4  ->  passed  [0.275s]
sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256:v6  ->  passed  [2.390s]
sys/netipsec/tunnel/aes_gcm_128:v4  ->  passed  [0.284s]
sys/netipsec/tunnel/aes_gcm_128:v6  ->  passed  [2.352s]
sys/netipsec/tunnel/aes_gcm_256:v4  ->  passed  [0.291s]
sys/netipsec/tunnel/aes_gcm_256:v6  ->  passed  [2.303s]
sys/netipsec/tunnel/aesni_aes_cbc_128_hmac_sha1:v4  ->  passed  [0.291s]
sys/netipsec/tunnel/aesni_aes_cbc_128_hmac_sha1:v6  ->  passed  [2.389s]
sys/netipsec/tunnel/aesni_aes_cbc_256_hmac_sha2_256:v4  ->  passed  [0.287s]
sys/netipsec/tunnel/aesni_aes_cbc_256_hmac_sha2_256:v6  ->  passed  [2.402s]
sys/netipsec/tunnel/aesni_aes_gcm_128:v4  ->  passed  [0.275s]
sys/netipsec/tunnel/aesni_aes_gcm_128:v6  ->  failed: atf-check failed; see the output of the test for details  [13.535s]
sys/netipsec/tunnel/aesni_aes_gcm_256:v4  ->  passed  [0.280s]
sys/netipsec/tunnel/aesni_aes_gcm_256:v6  ->  failed: atf-check failed; see the output of the test for details  [13.887s]
sys/netipsec/tunnel/empty:v4  ->  passed  [0.265s]
sys/netipsec/tunnel/empty:v6  ->  passed  [2.298s]

kp added inline comments.Nov 18 2017, 10:21 AM

tests/sys/netipsec/tunnel/utils.subr
90	I believe you're being held up by DAD here. The pf tests set no_dad.

Add no_dad to inet6 setup for avoiding a sleep

Harbormaster failed remote builds in B12855: Diff 35450!Nov 19 2017, 8:55 AM

Good catch for the no_dad!

Well, I suppose this is good, in that it shows why these tests are useful:

panic: hashdestroy: hashtbl 0xfffff8007d317c00 not empty (malloc type ipsecpolicy)
cpuid = 2
time = 1511388689
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0469c18650
vpanic() at vpanic+0x19c/frame 0xfffffe0469c186d0
kassert_panic() at kassert_panic+0x126/frame 0xfffffe0469c18740
hashdestroy() at hashdestroy+0x3b/frame 0xfffffe0469c18770
key_destroy() at key_destroy+0x368/frame 0xfffffe0469c187c0
vnet_destroy() at vnet_destroy+0x12c/frame 0xfffffe0469c187f0
prison_deref() at prison_deref+0x29c/frame 0xfffffe0469c18830
sys_jail_remove() at sys_jail_remove+0x2ac/frame 0xfffffe0469c18880
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe0469c189b0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0469c189b0

syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x800ea94ea, rsp = 0x7fffffffe828, rbp = 0x7fffffffe8a0 ---

KDB: enter: panic
[ thread pid 1386 tid 100744 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db>

Kristof and Olivier, can you test this patch?

ipsec.diff1 KBDownload

It looks like something's still wrong:

spin lock 0xffffffff81ece8a0 (smp rendezvous) held by 0xfffff80009602560 (tid 100674) too long
panic: spin lock held too long
cpuid = 7
time = 1511868134
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046994d320
vpanic() at vpanic+0x19c/frame 0xfffffe046994d3a0
panic() at panic+0x43/frame 0xfffffe046994d400
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x352/frame 0xfffffe046994d470
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xd8/frame 0xfffffe046994d4b0
smp_rendezvous_cpus() at smp_rendezvous_cpus+0xab/frame 0xfffffe046994d520
smp_rendezvous() at smp_rendezvous+0x40/frame 0xfffffe046994d550
counter_u64_alloc() at counter_u64_alloc+0x3e/frame 0xfffffe046994d570
vnet_espstat_init() at vnet_espstat_init+0x1a/frame 0xfffffe046994d590
vnet_alloc() at vnet_alloc+0x11c/frame 0xfffffe046994d5c0
kern_jail_set() at kern_jail_set+0x1bb4/frame 0xfffffe046994d850
sys_jail_set() at sys_jail_set+0x41/frame 0xfffffe046994d880
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe046994d9b0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046994d9b0
--- syscall (507, FreeBSD ELF64, sys_jail_set), rip = 0x800ea950a, rsp = 0x7fffffffe488, rbp = 0x7fffffffe570 ---
KDB: enter: panic
[ thread pid 2319 tid 100704 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db>

In D13017#276999, @kristof wrote:

It looks like something's still wrong:

spin lock 0xffffffff81ece8a0 (smp rendezvous) held by 0xfffff80009602560 (tid 100674) too long
panic: spin lock held too long
cpuid = 7
time = 1511868134
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046994d320
vpanic() at vpanic+0x19c/frame 0xfffffe046994d3a0
panic() at panic+0x43/frame 0xfffffe046994d400
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x352/frame 0xfffffe046994d470
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xd8/frame 0xfffffe046994d4b0
smp_rendezvous_cpus() at smp_rendezvous_cpus+0xab/frame 0xfffffe046994d520
smp_rendezvous() at smp_rendezvous+0x40/frame 0xfffffe046994d550
counter_u64_alloc() at counter_u64_alloc+0x3e/frame 0xfffffe046994d570
vnet_espstat_init() at vnet_espstat_init+0x1a/frame 0xfffffe046994d590
vnet_alloc() at vnet_alloc+0x11c/frame 0xfffffe046994d5c0
kern_jail_set() at kern_jail_set+0x1bb4/frame 0xfffffe046994d850
sys_jail_set() at sys_jail_set+0x41/frame 0xfffffe046994d880
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe046994d9b0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046994d9b0
--- syscall (507, FreeBSD ELF64, sys_jail_set), rip = 0x800ea950a, rsp = 0x7fffffffe488, rbp = 0x7fffffffe570 ---
KDB: enter: panic
[ thread pid 2319 tid 100704 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db>

That looks like recently reported mjg lock breakage.

I'll try again once I see a commit go by that looks like it'd fix that. Do feel free to remind me if I manage to miss it (or forget).

aes_cbc_128_hmac_sha1:v4  ->  passed  [1.642s]
aes_cbc_128_hmac_sha1:v6  ->  passed  [1.619s]
aes_cbc_256_hmac_sha2_256:v4  ->  passed  [1.617s]
aes_cbc_256_hmac_sha2_256:v6  ->  passed  [1.680s]
aes_gcm_128:v4  ->  passed  [1.605s]
aes_gcm_128:v6  ->  passed  [1.616s]
aes_gcm_256:v4  ->  passed  [1.844s]
aes_gcm_256:v6  ->  passed  [1.793s]
aesni_aes_cbc_128_hmac_sha1:v4  ->  passed  [1.579s]
aesni_aes_cbc_128_hmac_sha1:v6  ->  passed  [1.742s]
aesni_aes_cbc_256_hmac_sha2_256:v4  ->  passed  [1.601s]
aesni_aes_cbc_256_hmac_sha2_256:v6  ->  passed  [1.611s]
aesni_aes_gcm_128:v4  ->  passed  [1.602s]
aesni_aes_gcm_128:v6  ->  expected_failure: PR 201447: atf-check failed; see the output of the test for details  [12.928s]
aesni_aes_gcm_256:v4  ->  passed  [1.835s]
aesni_aes_gcm_256:v6  ->  expected_failure: PR 201447: atf-check failed; see the output of the test for details  [12.773s]
empty:v4  ->  passed  [1.577s]
empty:v6  ->  passed  [1.593s]

Much better now.
ae@'s patch fixes the IPSec panic. As soon as that goes in I think these tests can too.

Closed by commit rS326497: Add IPSec tests in tunnel mode (authored by kp). · Explain WhyDec 3 2017, 1:52 PM

This revision was automatically updated to reflect the committed changes.