lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Fri, 26 Apr 2019 08:15:11 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW_ACCEL



Begin forwarded message:

Date: Fri, 26 Apr 2019 11:06:27 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW_ACCEL


https://bugzilla.kernel.org/show_bug.cgi?id=203433

            Bug ID: 203433
           Summary: CONFIG_IXGBE_IPSEC forces HW_ACCEL
           Product: Networking
           Version: 2.5
    Kernel Version: 5.0.9
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: stephen@...workplumber.org
          Reporter: gheorghe@...ux.com
        Regression: No

The IXGBE_IPSEC module doesn't check if the child SA has HW_ACCEL enabled or
disabled, causing HW_ACCEL to be always enabled, even if, in some cases, there
is no support for it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c?h=v5.1-rc6#n1085

There should be a check to see if the SA has HW_ACCEL or not, something like
this: if (!xs->xso.offload_handle) return 1;

I noticed this when running StrongSwan within macvlan networks with Docker, on
ArchLinux, on this nic: 82599ES 10-Gigabit SFI/SFP+ Network Connection. The
connection is getting established and the packages are sent through the tunnel,
but if the IPsec server has some form of NAT (masquerade or SNAT), packages
don't get pushed out the 10 GbE device. This can be seen with `tcpdump -n -e -i
interface icmp`:
21:51:17.575688 84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800),
length 98: 10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
21:51:17.575717 02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800),
length 98: 139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length
64
## Here a reply should be seen, but there is none. On further inspection we
determined that packages are not sent out the interface, even if NAT can be
seen in the tcpdump.

The solution to make IPsec work was to recompile the kernel without
CONFIG_IXGBE_IPSEC (which is currently "y" by default on multiple
distributions, so we can expect this problem to appear in the future). After
this, NAT works for the IPsec connection and ICMP reply can be seen with
tcpdump on the interface:
84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98:
10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800), length 98:
139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98:
9.9.9.9 > 139.28.217.67: ICMP echo reply, id 10752, seq 1, length 64

Steps to reproduce
1. create an IPsec connection, without HW offload (StrongSwan has it off by
default, and it can also assign VIPs)
2. add masquerade for the VIPs, to go out the IXGBE nic.
3. tcpdump on the server and ping from the client

If I can help in any way on this case, please let me know.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Powered by blists - more mailing lists