netdev - Fw: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW

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.