Skip to content

Commit 8ce38ae

Browse files
davem330davem330
committed
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next
Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2017-12-15 1) Currently we can add or update socket policies, but not clear them. Support clearing of socket policies too. From Lorenzo Colitti. 2) Add documentation for the xfrm device offload api. From Shannon Nelson. 3) Fix IPsec extended sequence numbers (ESN) for IPsec offloading. From Yossef Efraim. 4) xfrm_dev_state_add function returns success even for unsupported options, fix this to fail in such cases. From Yossef Efraim. 5) Remove a redundant xfrm_state assignment. From Aviv Heller. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2 parents 3b07d78 + 9b7e14d commit 8ce38ae

File tree

7 files changed

+144
-5
lines changed

7 files changed

+144
-5
lines changed

‎Documentation/networking/00-INDEX

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -228,6 +228,8 @@ x25.txt
228228
- general info on X.25 development.
229229
x25-iface.txt
230230
- description of the X.25 Packet Layer to LAPB device interface.
231+
xfrm_device.txt
232+
- description of XFRM offload API
231233
xfrm_proc.txt
232234
- description of the statistics package for XFRM.
233235
xfrm_sync.txt

‎Documentation/networking/xfrm_device.txt

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
2+
===============================================
3+
XFRM device - offloading the IPsec computations
4+
===============================================
5+
Shannon Nelson <shannon.nelson@oracle.com>
6+
7+
8+
Overview
9+
========
10+
11+
IPsec is a useful feature for securing network traffic, but the
12+
computational cost is high: a 10Gbps link can easily be brought down
13+
to under 1Gbps, depending on the traffic and link configuration.
14+
Luckily, there are NICs that offer a hardware based IPsec offload which
15+
can radically increase throughput and decrease CPU utilization. The XFRM
16+
Device interface allows NIC drivers to offer to the stack access to the
17+
hardware offload.
18+
19+
Userland access to the offload is typically through a system such as
20+
libreswan or KAME/raccoon, but the iproute2 'ip xfrm' command set can
21+
be handy when experimenting. An example command might look something
22+
like this:
23+
24+
ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \
25+
reqid 0x07 replay-window 32 \
26+
aead 'rfc4106(gcm(aes))' 0x44434241343332312423222114131211f4f3f2f1 128 \
27+
sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp \
28+
offload dev eth4 dir in
29+
30+
Yes, that's ugly, but that's what shell scripts and/or libreswan are for.
31+
32+
33+
34+
Callbacks to implement
35+
======================
36+
37+
/* from include/linux/netdevice.h */
38+
struct xfrmdev_ops {
39+
int (*xdo_dev_state_add) (struct xfrm_state *x);
40+
void (*xdo_dev_state_delete) (struct xfrm_state *x);
41+
void (*xdo_dev_state_free) (struct xfrm_state *x);
42+
bool (*xdo_dev_offload_ok) (struct sk_buff *skb,
43+
struct xfrm_state *x);
44+
};
45+
46+
The NIC driver offering ipsec offload will need to implement these
47+
callbacks to make the offload available to the network stack's
48+
XFRM subsytem. Additionally, the feature bits NETIF_F_HW_ESP and
49+
NETIF_F_HW_ESP_TX_CSUM will signal the availability of the offload.
50+
51+
52+
53+
Flow
54+
====
55+
56+
At probe time and before the call to register_netdev(), the driver should
57+
set up local data structures and XFRM callbacks, and set the feature bits.
58+
The XFRM code's listener will finish the setup on NETDEV_REGISTER.
59+
60+
adapter->netdev->xfrmdev_ops = &ixgbe_xfrmdev_ops;
61+
adapter->netdev->features |= NETIF_F_HW_ESP;
62+
adapter->netdev->hw_enc_features |= NETIF_F_HW_ESP;
63+
64+
When new SAs are set up with a request for "offload" feature, the
65+
driver's xdo_dev_state_add() will be given the new SA to be offloaded
66+
and an indication of whether it is for Rx or Tx. The driver should
67+
- verify the algorithm is supported for offloads
68+
- store the SA information (key, salt, target-ip, protocol, etc)
69+
- enable the HW offload of the SA
70+
71+
The driver can also set an offload_handle in the SA, an opaque void pointer
72+
that can be used to convey context into the fast-path offload requests.
73+
74+
xs->xso.offload_handle = context;
75+
76+
77+
When the network stack is preparing an IPsec packet for an SA that has
78+
been setup for offload, it first calls into xdo_dev_offload_ok() with
79+
the skb and the intended offload state to ask the driver if the offload
80+
will serviceable. This can check the packet information to be sure the
81+
offload can be supported (e.g. IPv4 or IPv6, no IPv4 options, etc) and
82+
return true of false to signify its support.
83+
84+
When ready to send, the driver needs to inspect the Tx packet for the
85+
offload information, including the opaque context, and set up the packet
86+
send accordingly.
87+
88+
xs = xfrm_input_state(skb);
89+
context = xs->xso.offload_handle;
90+
set up HW for send
91+
92+
The stack has already inserted the appropriate IPsec headers in the
93+
packet data, the offload just needs to do the encryption and fix up the
94+
header values.
95+
96+
97+
When a packet is received and the HW has indicated that it offloaded a
98+
decryption, the driver needs to add a reference to the decoded SA into
99+
the packet's skb. At this point the data should be decrypted but the
100+
IPsec headers are still in the packet data; they are removed later up
101+
the stack in xfrm_input().
102+
103+
find and hold the SA that was used to the Rx skb
104+
get spi, protocol, and destination IP from packet headers
105+
xs = find xs from (spi, protocol, dest_IP)
106+
xfrm_state_hold(xs);
107+
108+
store the state information into the skb
109+
skb->sp = secpath_dup(skb->sp);
110+
skb->sp->xvec[skb->sp->len++] = xs;
111+
skb->sp->olen++;
112+
113+
indicate the success and/or error status of the offload
114+
xo = xfrm_offload(skb);
115+
xo->flags = CRYPTO_DONE;
116+
xo->status = crypto_status;
117+
118+
hand the packet to napi_gro_receive() as usual
119+
120+
121+
When the SA is removed by the user, the driver's xdo_dev_state_delete()
122+
is asked to disable the offload. Later, xdo_dev_state_free() is called
123+
from a garbage collection routine after all reference counts to the state
124+
have been removed and any remaining resources can be cleared for the
125+
offload state. How these are used by the driver will depend on specific
126+
hardware needs.
127+
128+
As a netdev is set to DOWN the XFRM stack's netdev listener will call
129+
xdo_dev_state_delete() and xdo_dev_state_free() on any remaining offloaded
130+
states.
131+
132+

‎net/xfrm/xfrm_device.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,7 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
6767

6868
/* We don't yet support UDP encapsulation, TFC padding and ESN. */
6969
if (x->encap || x->tfcpad || (x->props.flags & XFRM_STATE_ESN))
70-
return 0;
70+
return -EINVAL;
7171

7272
dev = dev_get_by_index(net, xuo->ifindex);
7373
if (!dev) {

‎net/xfrm/xfrm_input.c

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -231,7 +231,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
231231

232232
if (xo && (xo->flags & CRYPTO_DONE)) {
233233
crypto_done = true;
234-
x = xfrm_input_state(skb);
235234
family = XFRM_SPI_SKB_CB(skb)->family;
236235

237236
if (!(xo->status & CRYPTO_SUCCESS)) {

‎net/xfrm/xfrm_policy.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1251,7 +1251,7 @@ EXPORT_SYMBOL(xfrm_policy_delete);
12511251

12521252
int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
12531253
{
1254-
struct net *net = xp_net(pol);
1254+
struct net *net = sock_net(sk);
12551255
struct xfrm_policy *old_pol;
12561256

12571257
#ifdef CONFIG_XFRM_SUB_POLICY

‎net/xfrm/xfrm_replay.c

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -666,7 +666,7 @@ static int xfrm_replay_overflow_offload_esn(struct xfrm_state *x, struct sk_buff
666666
if (unlikely(oseq < replay_esn->oseq)) {
667667
XFRM_SKB_CB(skb)->seq.output.hi = ++oseq_hi;
668668
xo->seq.hi = oseq_hi;
669-
669+
replay_esn->oseq_hi = oseq_hi;
670670
if (replay_esn->oseq_hi == 0) {
671671
replay_esn->oseq--;
672672
replay_esn->oseq_hi--;
@@ -678,7 +678,6 @@ static int xfrm_replay_overflow_offload_esn(struct xfrm_state *x, struct sk_buff
678678
}
679679

680680
replay_esn->oseq = oseq;
681-
replay_esn->oseq_hi = oseq_hi;
682681

683682
if (xfrm_aevent_is_on(net))
684683
x->repl->notify(x, XFRM_REPLAY_UPDATE);

‎net/xfrm/xfrm_state.c

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2048,6 +2048,13 @@ int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval, int optlen
20482048
struct xfrm_mgr *km;
20492049
struct xfrm_policy *pol = NULL;
20502050

2051+
if (!optval && !optlen) {
2052+
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
2053+
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
2054+
__sk_dst_reset(sk);
2055+
return 0;
2056+
}
2057+
20512058
if (optlen <= 0 || optlen > PAGE_SIZE)
20522059
return -EMSGSIZE;
20532060

0 commit comments

Comments
 (0)