Bug 245832 - sys.netipsec.tunnel.empty.v{4,6} fail after r359374
Summary: sys.netipsec.tunnel.empty.v{4,6} fail after r359374
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: tests (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-testing (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-22 20:35 UTC by Li-Wen Hsu
Modified: 2020-05-04 11:24 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Li-Wen Hsu freebsd_committer 2020-04-22 20:35:52 UTC
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14710/testReport/sys.netipsec.tunnel/empty/v4/
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14710/testReport/sys.netipsec.tunnel/empty/v6/

stderr:

Files left in work directory after failure: created_interfaces.lst, created_jails.lst, ipsec.ipsecA.conf, ipsec.ipsecB.conf
ifconfig: interface epair0b does not exist
ifconfig: interface epair1b does not exist
ifconfig: interface epair2b does not exist
ifconfig: interface epair3b does not exist
Comment 1 Li-Wen Hsu freebsd_committer 2020-04-22 20:47:00 UTC
olivier, kp: I suspect that the ipsec config part of these tests may need to be adjusted, could you help check it? Thanks!
Comment 2 commit-hook freebsd_committer 2020-04-22 20:50:37 UTC
A commit references this bug:

Author: lwhsu
Date: Wed Apr 22 20:50:24 UTC 2020
New revision: 360204
URL: https://svnweb.freebsd.org/changeset/base/360204

Log:
  Temporarily skip sys.netipsec.tunnel.empty.v{4,6} in CI

  PR:		245832
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/tests/sys/netipsec/tunnel/empty.sh
Comment 3 Olivier Cochard freebsd_committer 2020-04-22 21:01:32 UTC
Does it mean that r359374 removed the support of 'null' algo ?
Because there is no reference to the removal of this algorithm in the commit message of  r359374.
Comment 4 Li-Wen Hsu freebsd_committer 2020-04-22 21:26:59 UTC
(In reply to Olivier Cochard from comment #3)
> Does it mean that r359374 removed the support of 'null' algo ?
I suspect but I am not 100% sure. jhb and cem, could you help check about this?
Comment 5 John Baldwin freebsd_committer freebsd_triage 2020-04-22 21:45:33 UTC
No, null should still be there, and I had tested using some setkey configurations with a null cipher, but is probably some sort of regression in r359374.
Comment 6 John Baldwin freebsd_committer freebsd_triage 2020-05-01 22:11:04 UTC
I just retested null on stock HEAD and it worked for me.  I used the following setkey configurations:

host with 172.16.0.1 interface:

flush;
spdflush;
# Host to host ESP
# Security Associations
add 172.16.0.1 172.16.0.2 esp 0x10000 -E null 0xffff;
add 172.16.0.2 172.16.0.1 esp 0x10001 -E null 0xffff;
# Security Policies
spdadd 172.16.0.1 172.16.0.2 any -P out ipsec esp/tunnel/172.16.0.1-172.16.0.2/require;
spdadd 172.16.0.2 172.16.0.1 any -P in ipsec esp/tunnel/172.16.0.2-172.16.0.1/require;

Host with 172.16.0.2 interface:

flush;
spdflush;
# Host to host ESP
# Security Associations
add 172.16.0.1 172.16.0.2 esp 0x10000 -E null 0xffff;
add 172.16.0.2 172.16.0.1 esp 0x10001 -E null 0xffff;
# Security Policies
spdadd 172.16.0.1 172.16.0.2 any -P in ipsec esp/tunnel/172.16.0.1-172.16.0.2/require;
spdadd 172.16.0.2 172.16.0.1 any -P out ipsec esp/tunnel/172.16.0.2-172.16.0.1/require;

I'll look to see what kind of setkey config files the test creates, but I didn't change any of the parsing for setkey in the OCF rework changes, and I would expect setkey to report an error to stderr (which it didn't from what I can tell) if it had a parse error or got an error back when trying to setup the SA.
Comment 7 John Baldwin freebsd_committer freebsd_triage 2020-05-01 23:18:15 UTC
kyua actively makes this hard to investigate.  I can't get it to leave the setkey config files around (kyua debug only redirects stdout/stderr which is useless in this case).

So, I ran the entire test under ktrace and used kdump to figure out what it wrote.  It appears to have used an encryption key of "", and even though the test fails to report the error from setkey, trying that directly does error (so would be nice if we could get the test to report stderr output from jexec'd things to stderr):

# setkey -f /mnt/jhb/work/git/netperf/IPSEC/Configs/source-null.conf
The result of line 8: Invalid argument.
The result of line 9: Invalid argument.

But I'll track it down from here since I can reproduce.
Comment 8 commit-hook freebsd_committer 2020-05-02 01:00:52 UTC
A commit references this bug:

Author: jhb
Date: Sat May  2 01:00:30 UTC 2020
New revision: 360560
URL: https://svnweb.freebsd.org/changeset/base/360560

Log:
  Don't pass bogus keys down for NULL algorithms.

  The changes in r359374 added various sanity checks in sessions and
  requests created by crypto consumers in part to permit backend drivers
  to make assumptions instead of duplicating checks for various edge
  cases.  One of the new checks was to reject sessions which provide a
  pointer to a key while claiming the key is zero bits long.

  IPsec ESP tripped over this as it passes along whatever key is
  provided for NULL, including a pointer to a zero-length key when an
  empty string ("") is used with setkey(8).  One option would be to
  teach the IPsec key layer to not allocate keys of zero length, but I
  went with a simpler fix of just not passing any keys down and always
  using a key length of zero for NULL algorithms.

  PR:		245832
  Reported by:	CI

Changes:
  head/sys/netipsec/xform_ah.c
  head/sys/netipsec/xform_esp.c
Comment 9 John Baldwin freebsd_committer freebsd_triage 2020-05-02 01:01:24 UTC
I've committed a fix.  All of the IPsec tunnel tests pass for me now.  I'll let Li-wen re-enable the tests after verifying the fix.
Comment 10 Li-Wen Hsu freebsd_committer 2020-05-04 11:24:24 UTC
Fix verified. Thanks!
Comment 11 commit-hook freebsd_committer 2020-05-04 11:24:37 UTC
A commit references this bug:

Author: lwhsu
Date: Mon May  4 11:23:56 UTC 2020
New revision: 360626
URL: https://svnweb.freebsd.org/changeset/base/360626

Log:
  Revert r360204, sys.netipsec.tunnel.empty.v{4,6} are fixed by r360560

  PR:		245832
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/tests/sys/netipsec/tunnel/empty.sh