2007-02-09 14:24:47 +00:00
|
|
|
/*
|
2005-04-16 22:20:36 +00:00
|
|
|
* xfrm4_policy.c
|
|
|
|
*
|
|
|
|
* Changes:
|
|
|
|
* Kazunori MIYAZAWA @USAGI
|
|
|
|
* YOSHIFUJI Hideaki @USAGI
|
|
|
|
* Split up af-specific portion
|
2007-02-09 14:24:47 +00:00
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
2007-11-14 05:37:28 +00:00
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/kernel.h>
|
2005-05-03 23:27:10 +00:00
|
|
|
#include <linux/inetdevice.h>
|
2010-11-03 04:41:38 +00:00
|
|
|
#include <linux/if_tunnel.h>
|
2007-11-14 05:35:32 +00:00
|
|
|
#include <net/dst.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <net/xfrm.h>
|
|
|
|
#include <net/ip.h>
|
2015-09-30 03:07:13 +00:00
|
|
|
#include <net/l3mdev.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-05-09 22:13:28 +00:00
|
|
|
static struct dst_entry *__xfrm4_dst_lookup(struct net *net, struct flowi4 *fl4,
|
2015-08-10 22:58:11 +00:00
|
|
|
int tos, int oif,
|
2011-05-09 22:13:28 +00:00
|
|
|
const xfrm_address_t *saddr,
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
const xfrm_address_t *daddr,
|
|
|
|
u32 mark)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-11-14 05:37:28 +00:00
|
|
|
struct rtable *rt;
|
2006-09-19 19:57:34 +00:00
|
|
|
|
2011-05-09 22:13:28 +00:00
|
|
|
memset(fl4, 0, sizeof(*fl4));
|
|
|
|
fl4->daddr = daddr->a4;
|
|
|
|
fl4->flowi4_tos = tos;
|
2016-08-15 02:52:56 +00:00
|
|
|
fl4->flowi4_oif = l3mdev_master_ifindex_by_index(net, oif);
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
fl4->flowi4_mark = mark;
|
2007-11-14 05:37:28 +00:00
|
|
|
if (saddr)
|
2011-05-09 22:13:28 +00:00
|
|
|
fl4->saddr = saddr->a4;
|
2007-11-14 05:37:28 +00:00
|
|
|
|
2015-09-15 22:10:50 +00:00
|
|
|
fl4->flowi4_flags = FLOWI_FLAG_SKIP_NH_OIF;
|
|
|
|
|
2011-05-09 22:13:28 +00:00
|
|
|
rt = __ip_route_output_key(net, fl4);
|
2011-03-02 22:31:35 +00:00
|
|
|
if (!IS_ERR(rt))
|
|
|
|
return &rt->dst;
|
|
|
|
|
|
|
|
return ERR_CAST(rt);
|
2007-11-14 05:37:28 +00:00
|
|
|
}
|
|
|
|
|
2015-08-10 22:58:11 +00:00
|
|
|
static struct dst_entry *xfrm4_dst_lookup(struct net *net, int tos, int oif,
|
2011-05-09 22:13:28 +00:00
|
|
|
const xfrm_address_t *saddr,
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
const xfrm_address_t *daddr,
|
|
|
|
u32 mark)
|
2011-05-09 22:13:28 +00:00
|
|
|
{
|
|
|
|
struct flowi4 fl4;
|
|
|
|
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
return __xfrm4_dst_lookup(net, &fl4, tos, oif, saddr, daddr, mark);
|
2011-05-09 22:13:28 +00:00
|
|
|
}
|
|
|
|
|
2015-08-10 22:58:11 +00:00
|
|
|
static int xfrm4_get_saddr(struct net *net, int oif,
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
xfrm_address_t *saddr, xfrm_address_t *daddr,
|
|
|
|
u32 mark)
|
2007-11-14 05:37:28 +00:00
|
|
|
{
|
|
|
|
struct dst_entry *dst;
|
2011-05-09 22:13:28 +00:00
|
|
|
struct flowi4 fl4;
|
2007-11-14 05:37:28 +00:00
|
|
|
|
net: xfrm: support setting an output mark.
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2017-08-10 17:11:33 +00:00
|
|
|
dst = __xfrm4_dst_lookup(net, &fl4, 0, oif, NULL, daddr, mark);
|
2007-11-14 05:37:28 +00:00
|
|
|
if (IS_ERR(dst))
|
|
|
|
return -EHOSTUNREACH;
|
|
|
|
|
2011-05-09 22:13:28 +00:00
|
|
|
saddr->a4 = fl4.saddr;
|
2007-11-14 05:37:28 +00:00
|
|
|
dst_release(dst);
|
|
|
|
return 0;
|
2006-09-19 19:57:34 +00:00
|
|
|
}
|
|
|
|
|
2011-02-23 01:47:10 +00:00
|
|
|
static int xfrm4_get_tos(const struct flowi *fl)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-03-12 07:42:11 +00:00
|
|
|
return IPTOS_RT_MASK & fl->u.ip4.flowi4_tos; /* Strip ECN bits */
|
2007-12-11 17:32:34 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-12-21 04:41:12 +00:00
|
|
|
static int xfrm4_init_path(struct xfrm_dst *path, struct dst_entry *dst,
|
|
|
|
int nfheader_len)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-03-02 02:51:56 +00:00
|
|
|
static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
|
2011-02-23 01:48:57 +00:00
|
|
|
const struct flowi *fl)
|
2007-12-11 17:32:34 +00:00
|
|
|
{
|
|
|
|
struct rtable *rt = (struct rtable *)xdst->route;
|
2011-03-12 07:42:11 +00:00
|
|
|
const struct flowi4 *fl4 = &fl->u.ip4;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-10-22 21:58:20 +00:00
|
|
|
xdst->u.rt.rt_iif = fl4->flowi4_iif;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-12-11 17:32:34 +00:00
|
|
|
xdst->u.dst.dev = dev;
|
|
|
|
dev_hold(dev);
|
2007-02-06 22:27:32 +00:00
|
|
|
|
2007-12-11 17:32:34 +00:00
|
|
|
/* Sheit... I remember I did this right. Apparently,
|
|
|
|
* it was magically lost, so this code needs audit */
|
2012-07-17 21:44:26 +00:00
|
|
|
xdst->u.rt.rt_is_input = rt->rt_is_input;
|
2007-12-11 17:32:34 +00:00
|
|
|
xdst->u.rt.rt_flags = rt->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST |
|
|
|
|
RTCF_LOCAL);
|
|
|
|
xdst->u.rt.rt_type = rt->rt_type;
|
|
|
|
xdst->u.rt.rt_gateway = rt->rt_gateway;
|
2012-10-08 11:41:18 +00:00
|
|
|
xdst->u.rt.rt_uses_gateway = rt->rt_uses_gateway;
|
2012-07-10 13:58:42 +00:00
|
|
|
xdst->u.rt.rt_pmtu = rt->rt_pmtu;
|
2015-09-02 20:58:35 +00:00
|
|
|
xdst->u.rt.rt_table_id = rt->rt_table_id;
|
2012-07-31 22:06:50 +00:00
|
|
|
INIT_LIST_HEAD(&xdst->u.rt.rt_uncached);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2007-12-12 18:44:16 +00:00
|
|
|
_decode_session4(struct sk_buff *skb, struct flowi *fl, int reverse)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-04-22 04:53:02 +00:00
|
|
|
const struct iphdr *iph = ip_hdr(skb);
|
2007-04-11 03:50:43 +00:00
|
|
|
u8 *xprth = skb_network_header(skb) + iph->ihl * 4;
|
2011-03-12 07:42:11 +00:00
|
|
|
struct flowi4 *fl4 = &fl->u.ip4;
|
2013-10-30 10:16:28 +00:00
|
|
|
int oif = 0;
|
|
|
|
|
2015-09-30 03:07:13 +00:00
|
|
|
if (skb_dst(skb))
|
2016-09-10 19:09:57 +00:00
|
|
|
oif = skb_dst(skb)->dev->ifindex;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 07:42:11 +00:00
|
|
|
memset(fl4, 0, sizeof(struct flowi4));
|
|
|
|
fl4->flowi4_mark = skb->mark;
|
2013-10-30 10:16:28 +00:00
|
|
|
fl4->flowi4_oif = reverse ? skb->skb_iif : oif;
|
2010-07-02 07:47:55 +00:00
|
|
|
|
2011-06-22 03:33:34 +00:00
|
|
|
if (!ip_is_fragment(iph)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
switch (iph->protocol) {
|
|
|
|
case IPPROTO_UDP:
|
2006-11-27 19:10:57 +00:00
|
|
|
case IPPROTO_UDPLITE:
|
2005-04-16 22:20:36 +00:00
|
|
|
case IPPROTO_TCP:
|
|
|
|
case IPPROTO_SCTP:
|
2005-12-19 22:03:46 +00:00
|
|
|
case IPPROTO_DCCP:
|
2009-07-02 16:57:23 +00:00
|
|
|
if (xprth + 4 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 4 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
__be16 *ports;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
ports = (__be16 *)xprth;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_sport = ports[!!reverse];
|
|
|
|
fl4->fl4_dport = ports[!reverse];
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPPROTO_ICMP:
|
2015-10-23 05:31:23 +00:00
|
|
|
if (xprth + 2 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 2 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
u8 *icmp;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
icmp = xprth;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_icmp_type = icmp[0];
|
|
|
|
fl4->fl4_icmp_code = icmp[1];
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPPROTO_ESP:
|
2015-10-23 05:31:23 +00:00
|
|
|
if (xprth + 4 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 4 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
__be32 *ehdr;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
ehdr = (__be32 *)xprth;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_ipsec_spi = ehdr[0];
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPPROTO_AH:
|
2015-10-23 05:31:23 +00:00
|
|
|
if (xprth + 8 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 8 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
__be32 *ah_hdr;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
ah_hdr = (__be32 *)xprth;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_ipsec_spi = ah_hdr[1];
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPPROTO_COMP:
|
2015-10-23 05:31:23 +00:00
|
|
|
if (xprth + 4 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 4 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
__be16 *ipcomp_hdr;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
ipcomp_hdr = (__be16 *)xprth;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_ipsec_spi = htonl(ntohs(ipcomp_hdr[1]));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
2010-11-03 04:41:38 +00:00
|
|
|
|
|
|
|
case IPPROTO_GRE:
|
2015-10-23 05:31:23 +00:00
|
|
|
if (xprth + 12 < skb->data ||
|
|
|
|
pskb_may_pull(skb, xprth + 12 - skb->data)) {
|
2015-10-23 05:32:39 +00:00
|
|
|
__be16 *greflags;
|
|
|
|
__be32 *gre_hdr;
|
|
|
|
|
|
|
|
xprth = skb_network_header(skb) + iph->ihl * 4;
|
|
|
|
greflags = (__be16 *)xprth;
|
|
|
|
gre_hdr = (__be32 *)xprth;
|
2010-11-03 04:41:38 +00:00
|
|
|
|
|
|
|
if (greflags[0] & GRE_KEY) {
|
|
|
|
if (greflags[0] & GRE_CSUM)
|
|
|
|
gre_hdr++;
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_gre_key = gre_hdr[1];
|
2010-11-03 04:41:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
default:
|
2011-03-12 08:00:33 +00:00
|
|
|
fl4->fl4_ipsec_spi = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2007-04-21 00:09:22 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2011-03-12 07:42:11 +00:00
|
|
|
fl4->flowi4_proto = iph->protocol;
|
|
|
|
fl4->daddr = reverse ? iph->saddr : iph->daddr;
|
|
|
|
fl4->saddr = reverse ? iph->daddr : iph->saddr;
|
|
|
|
fl4->flowi4_tos = iph->tos;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2012-07-17 10:29:28 +00:00
|
|
|
static void xfrm4_update_pmtu(struct dst_entry *dst, struct sock *sk,
|
|
|
|
struct sk_buff *skb, u32 mtu)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
|
|
|
|
struct dst_entry *path = xdst->route;
|
|
|
|
|
2012-07-17 10:29:28 +00:00
|
|
|
path->ops->update_pmtu(path, sk, skb, mtu);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2012-07-17 10:29:28 +00:00
|
|
|
static void xfrm4_redirect(struct dst_entry *dst, struct sock *sk,
|
|
|
|
struct sk_buff *skb)
|
2012-07-12 04:27:49 +00:00
|
|
|
{
|
|
|
|
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
|
|
|
|
struct dst_entry *path = xdst->route;
|
|
|
|
|
2012-07-17 10:29:28 +00:00
|
|
|
path->ops->redirect(path, sk, skb);
|
2012-07-12 04:27:49 +00:00
|
|
|
}
|
|
|
|
|
2005-05-03 23:27:10 +00:00
|
|
|
static void xfrm4_dst_destroy(struct dst_entry *dst)
|
|
|
|
{
|
|
|
|
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
|
|
|
|
|
net: Implement read-only protection and COW'ing of metrics.
Routing metrics are now copy-on-write.
Initially a route entry points it's metrics at a read-only location.
If a routing table entry exists, it will point there. Else it will
point at the all zero metric place-holder called 'dst_default_metrics'.
The writeability state of the metrics is stored in the low bits of the
metrics pointer, we have two bits left to spare if we want to store
more states.
For the initial implementation, COW is implemented simply via kmalloc.
However future enhancements will change this to place the writable
metrics somewhere else, in order to increase sharing. Very likely
this "somewhere else" will be the inetpeer cache.
Note also that this means that metrics updates may transiently fail
if we cannot COW the metrics successfully.
But even by itself, this patch should decrease memory usage and
increase cache locality especially for routing workloads. In those
cases the read-only metric copies stay in place and never get written
to.
TCP workloads where metrics get updated, and those rare cases where
PMTU triggers occur, will take a very slight performance hit. But
that hit will be alleviated when the long-term writable metrics
move to a more sharable location.
Since the metrics storage went from a u32 array of RTAX_MAX entries to
what is essentially a pointer, some retooling of the dst_entry layout
was necessary.
Most importantly, we need to preserve the alignment of the reference
count so that it doesn't share cache lines with the read-mostly state,
as per Eric Dumazet's alignment assertion checks.
The only non-trivial bit here is the move of the 'flags' member into
the writeable cacheline. This is OK since we are always accessing the
flags around the same moment when we made a modification to the
reference count.
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-01-27 04:51:05 +00:00
|
|
|
dst_destroy_metrics_generic(dst);
|
|
|
|
|
2005-05-03 23:27:10 +00:00
|
|
|
xfrm_dst_destroy(xdst);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xfrm4_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
|
|
|
|
int unregister)
|
|
|
|
{
|
|
|
|
if (!unregister)
|
|
|
|
return;
|
|
|
|
|
|
|
|
xfrm_dst_ifdown(dst, dev);
|
|
|
|
}
|
|
|
|
|
2015-10-29 13:51:16 +00:00
|
|
|
static struct dst_ops xfrm4_dst_ops_template = {
|
2005-04-16 22:20:36 +00:00
|
|
|
.family = AF_INET,
|
|
|
|
.update_pmtu = xfrm4_update_pmtu,
|
2012-07-12 04:27:49 +00:00
|
|
|
.redirect = xfrm4_redirect,
|
net: Implement read-only protection and COW'ing of metrics.
Routing metrics are now copy-on-write.
Initially a route entry points it's metrics at a read-only location.
If a routing table entry exists, it will point there. Else it will
point at the all zero metric place-holder called 'dst_default_metrics'.
The writeability state of the metrics is stored in the low bits of the
metrics pointer, we have two bits left to spare if we want to store
more states.
For the initial implementation, COW is implemented simply via kmalloc.
However future enhancements will change this to place the writable
metrics somewhere else, in order to increase sharing. Very likely
this "somewhere else" will be the inetpeer cache.
Note also that this means that metrics updates may transiently fail
if we cannot COW the metrics successfully.
But even by itself, this patch should decrease memory usage and
increase cache locality especially for routing workloads. In those
cases the read-only metric copies stay in place and never get written
to.
TCP workloads where metrics get updated, and those rare cases where
PMTU triggers occur, will take a very slight performance hit. But
that hit will be alleviated when the long-term writable metrics
move to a more sharable location.
Since the metrics storage went from a u32 array of RTAX_MAX entries to
what is essentially a pointer, some retooling of the dst_entry layout
was necessary.
Most importantly, we need to preserve the alignment of the reference
count so that it doesn't share cache lines with the read-mostly state,
as per Eric Dumazet's alignment assertion checks.
The only non-trivial bit here is the move of the 'flags' member into
the writeable cacheline. This is OK since we are always accessing the
flags around the same moment when we made a modification to the
reference count.
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-01-27 04:51:05 +00:00
|
|
|
.cow_metrics = dst_cow_metrics_generic,
|
2005-05-03 23:27:10 +00:00
|
|
|
.destroy = xfrm4_dst_destroy,
|
|
|
|
.ifdown = xfrm4_dst_ifdown,
|
2007-11-14 05:43:11 +00:00
|
|
|
.local_out = __ip_local_out,
|
2017-07-17 11:57:20 +00:00
|
|
|
.gc_thresh = 32768,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2017-02-07 14:00:19 +00:00
|
|
|
static const struct xfrm_policy_afinfo xfrm4_policy_afinfo = {
|
2015-10-29 13:51:16 +00:00
|
|
|
.dst_ops = &xfrm4_dst_ops_template,
|
2005-04-16 22:20:36 +00:00
|
|
|
.dst_lookup = xfrm4_dst_lookup,
|
2006-09-19 19:57:34 +00:00
|
|
|
.get_saddr = xfrm4_get_saddr,
|
2005-04-16 22:20:36 +00:00
|
|
|
.decode_session = _decode_session4,
|
2007-12-11 17:32:34 +00:00
|
|
|
.get_tos = xfrm4_get_tos,
|
2007-12-21 04:41:12 +00:00
|
|
|
.init_path = xfrm4_init_path,
|
2007-12-11 17:32:34 +00:00
|
|
|
.fill_dst = xfrm4_fill_dst,
|
2011-03-01 22:59:04 +00:00
|
|
|
.blackhole_route = ipv4_blackhole_route,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2009-08-05 03:18:33 +00:00
|
|
|
#ifdef CONFIG_SYSCTL
|
2009-07-27 08:22:46 +00:00
|
|
|
static struct ctl_table xfrm4_policy_table[] = {
|
|
|
|
{
|
|
|
|
.procname = "xfrm4_gc_thresh",
|
2010-01-25 06:47:53 +00:00
|
|
|
.data = &init_net.xfrm.xfrm4_dst_ops.gc_thresh,
|
2009-07-27 08:22:46 +00:00
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec,
|
|
|
|
},
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2016-06-16 13:59:25 +00:00
|
|
|
static __net_init int xfrm4_net_sysctl_init(struct net *net)
|
2013-02-06 09:46:33 +00:00
|
|
|
{
|
|
|
|
struct ctl_table *table;
|
|
|
|
struct ctl_table_header *hdr;
|
|
|
|
|
|
|
|
table = xfrm4_policy_table;
|
|
|
|
if (!net_eq(net, &init_net)) {
|
|
|
|
table = kmemdup(table, sizeof(xfrm4_policy_table), GFP_KERNEL);
|
|
|
|
if (!table)
|
|
|
|
goto err_alloc;
|
|
|
|
|
|
|
|
table[0].data = &net->xfrm.xfrm4_dst_ops.gc_thresh;
|
|
|
|
}
|
|
|
|
|
|
|
|
hdr = register_net_sysctl(net, "net/ipv4", table);
|
|
|
|
if (!hdr)
|
|
|
|
goto err_reg;
|
|
|
|
|
|
|
|
net->ipv4.xfrm4_hdr = hdr;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_reg:
|
|
|
|
if (!net_eq(net, &init_net))
|
|
|
|
kfree(table);
|
|
|
|
err_alloc:
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2016-06-16 13:59:25 +00:00
|
|
|
static __net_exit void xfrm4_net_sysctl_exit(struct net *net)
|
2013-02-06 09:46:33 +00:00
|
|
|
{
|
|
|
|
struct ctl_table *table;
|
|
|
|
|
2015-04-03 08:17:26 +00:00
|
|
|
if (!net->ipv4.xfrm4_hdr)
|
2013-02-06 09:46:33 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
table = net->ipv4.xfrm4_hdr->ctl_table_arg;
|
|
|
|
unregister_net_sysctl_table(net->ipv4.xfrm4_hdr);
|
|
|
|
if (!net_eq(net, &init_net))
|
|
|
|
kfree(table);
|
|
|
|
}
|
2015-10-29 13:51:16 +00:00
|
|
|
#else /* CONFIG_SYSCTL */
|
2016-06-16 13:59:25 +00:00
|
|
|
static inline int xfrm4_net_sysctl_init(struct net *net)
|
2015-10-29 13:51:16 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-16 13:59:25 +00:00
|
|
|
static inline void xfrm4_net_sysctl_exit(struct net *net)
|
2015-10-29 13:51:16 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static int __net_init xfrm4_net_init(struct net *net)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
memcpy(&net->xfrm.xfrm4_dst_ops, &xfrm4_dst_ops_template,
|
|
|
|
sizeof(xfrm4_dst_ops_template));
|
|
|
|
ret = dst_entries_init(&net->xfrm.xfrm4_dst_ops);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = xfrm4_net_sysctl_init(net);
|
|
|
|
if (ret)
|
|
|
|
dst_entries_destroy(&net->xfrm.xfrm4_dst_ops);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __net_exit xfrm4_net_exit(struct net *net)
|
|
|
|
{
|
|
|
|
xfrm4_net_sysctl_exit(net);
|
|
|
|
dst_entries_destroy(&net->xfrm.xfrm4_dst_ops);
|
|
|
|
}
|
2013-02-06 09:46:33 +00:00
|
|
|
|
|
|
|
static struct pernet_operations __net_initdata xfrm4_net_ops = {
|
|
|
|
.init = xfrm4_net_init,
|
|
|
|
.exit = xfrm4_net_exit,
|
|
|
|
};
|
2009-07-27 08:22:46 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static void __init xfrm4_policy_init(void)
|
|
|
|
{
|
2017-02-07 14:00:17 +00:00
|
|
|
xfrm_policy_register_afinfo(&xfrm4_policy_afinfo, AF_INET);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2012-11-13 07:52:24 +00:00
|
|
|
void __init xfrm4_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-01-25 06:47:53 +00:00
|
|
|
xfrm4_state_init();
|
|
|
|
xfrm4_policy_init();
|
2014-03-14 06:28:07 +00:00
|
|
|
xfrm4_protocol_init();
|
2013-02-06 09:46:33 +00:00
|
|
|
register_pernet_subsys(&xfrm4_net_ops);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|