[bpf-next,v3,4/5] bpf: Add helpers to issue and check SYN cookies in XDP

Commit Message

Maxim Mikityanskiy Feb. 24, 2022, 3:11 p.m. UTC

The new helpers bpf_tcp_raw_{gen,check}_syncookie_ipv{4,6} allow an XDP
program to generate SYN cookies in response to TCP SYN packets and to
check those cookies upon receiving the first ACK packet (the final
packet of the TCP handshake).

Unlike bpf_tcp_{gen,check}_syncookie these new helpers don't need a
listening socket on the local machine, which allows to use them together
with synproxy to accelerate SYN cookie generation.

Signed-off-by: Maxim Mikityanskiy <[e-mail]>
Reviewed-by: Tariq Toukan <[e-mail]>
---
 include/net/tcp.h              |   1 +
 include/uapi/linux/bpf.h       |  90 +++++++++++++++++++++++
 net/core/filter.c              | 126 +++++++++++++++++++++++++++++++++
 net/ipv4/tcp_input.c           |   3 +-
 scripts/bpf_doc.py             |   4 ++
 tools/include/uapi/linux/bpf.h |  90 +++++++++++++++++++++++
 6 files changed, 313 insertions(+), 1 deletion(-)

Comments

Alexei Starovoitov Feb. 27, 2022, 3:25 a.m. UTC | #1

On Thu, Feb 24, 2022 at 05:11:44PM +0200, Maxim Mikityanskiy wrote:
> @@ -7798,6 +7916,14 @@ xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>  		return &bpf_tcp_check_syncookie_proto;
>  	case BPF_FUNC_tcp_gen_syncookie:
>  		return &bpf_tcp_gen_syncookie_proto;
> +	case BPF_FUNC_tcp_raw_gen_syncookie_ipv4:
> +		return &bpf_tcp_raw_gen_syncookie_ipv4_proto;
> +	case BPF_FUNC_tcp_raw_gen_syncookie_ipv6:
> +		return &bpf_tcp_raw_gen_syncookie_ipv6_proto;
> +	case BPF_FUNC_tcp_raw_check_syncookie_ipv4:
> +		return &bpf_tcp_raw_check_syncookie_ipv4_proto;
> +	case BPF_FUNC_tcp_raw_check_syncookie_ipv6:
> +		return &bpf_tcp_raw_check_syncookie_ipv6_proto;
>  #endif

I understand that the main use case for new helpers is XDP specific,
but why limit them to XDP?
The feature looks generic and applicable to skb too.

Maxim Mikityanskiy March 11, 2022, 4:36 p.m. UTC | #2

> -----Original Message-----
> From: Alexei Starovoitov <[e-mail]>
> Sent: 27 February, 2022 05:25
> 
> On Thu, Feb 24, 2022 at 05:11:44PM +0200, Maxim Mikityanskiy wrote:
> > @@ -7798,6 +7916,14 @@ xdp_func_proto(enum bpf_func_id func_id, const
> struct bpf_prog *prog)
> >  		return &bpf_tcp_check_syncookie_proto;
> >  	case BPF_FUNC_tcp_gen_syncookie:
> >  		return &bpf_tcp_gen_syncookie_proto;
> > +	case BPF_FUNC_tcp_raw_gen_syncookie_ipv4:
> > +		return &bpf_tcp_raw_gen_syncookie_ipv4_proto;
> > +	case BPF_FUNC_tcp_raw_gen_syncookie_ipv6:
> > +		return &bpf_tcp_raw_gen_syncookie_ipv6_proto;
> > +	case BPF_FUNC_tcp_raw_check_syncookie_ipv4:
> > +		return &bpf_tcp_raw_check_syncookie_ipv4_proto;
> > +	case BPF_FUNC_tcp_raw_check_syncookie_ipv6:
> > +		return &bpf_tcp_raw_check_syncookie_ipv6_proto;
> >  #endif
> 
> I understand that the main use case for new helpers is XDP specific,
> but why limit them to XDP?
> The feature looks generic and applicable to skb too.

That sounds like an extra feature, rather than a limitation. That's out
of scope of what I planned to do.

Besides, it sounds kind of useless to me, because the intention of the
new helpers is to accelerate synproxy, and I doubt BPF over SKBs will
accelerate anything. Maybe someone else has another use case for these
helpers and SKBs - in that case I leave the opportunity to add this
feature up to them.

Alexei Starovoitov March 11, 2022, 5:30 p.m. UTC | #3

On Fri, Mar 11, 2022 at 8:36 AM Maxim Mikityanskiy <[e-mail]> wrote:
>
> > -----Original Message-----
> > From: Alexei Starovoitov <[e-mail]>
> > Sent: 27 February, 2022 05:25
> >
> > On Thu, Feb 24, 2022 at 05:11:44PM +0200, Maxim Mikityanskiy wrote:
> > > @@ -7798,6 +7916,14 @@ xdp_func_proto(enum bpf_func_id func_id, const
> > struct bpf_prog *prog)
> > >             return &bpf_tcp_check_syncookie_proto;
> > >     case BPF_FUNC_tcp_gen_syncookie:
> > >             return &bpf_tcp_gen_syncookie_proto;
> > > +   case BPF_FUNC_tcp_raw_gen_syncookie_ipv4:
> > > +           return &bpf_tcp_raw_gen_syncookie_ipv4_proto;
> > > +   case BPF_FUNC_tcp_raw_gen_syncookie_ipv6:
> > > +           return &bpf_tcp_raw_gen_syncookie_ipv6_proto;
> > > +   case BPF_FUNC_tcp_raw_check_syncookie_ipv4:
> > > +           return &bpf_tcp_raw_check_syncookie_ipv4_proto;
> > > +   case BPF_FUNC_tcp_raw_check_syncookie_ipv6:
> > > +           return &bpf_tcp_raw_check_syncookie_ipv6_proto;
> > >  #endif
> >
> > I understand that the main use case for new helpers is XDP specific,
> > but why limit them to XDP?
> > The feature looks generic and applicable to skb too.
>
> That sounds like an extra feature, rather than a limitation. That's out
> of scope of what I planned to do.
>
> Besides, it sounds kind of useless to me, because the intention of the
> new helpers is to accelerate synproxy, and I doubt BPF over SKBs will
> accelerate anything. Maybe someone else has another use case for these
> helpers and SKBs - in that case I leave the opportunity to add this
> feature up to them.

This patchset will not be accepted until the feature is generalized
to both xdp and skb and tested for both.
"I dont have a use case for it" is not an excuse to narrow down the scope.

Maxim Mikityanskiy March 14, 2022, 5:49 p.m. UTC | #4

> -----Original Message-----
> From: Alexei Starovoitov <[e-mail]>
> 
> On Fri, Mar 11, 2022 at 8:36 AM Maxim Mikityanskiy <[e-mail]>
> wrote:
> >
> > > -----Original Message-----
> > > From: Alexei Starovoitov <[e-mail]>
> > > Sent: 27 February, 2022 05:25
> > >
> > > On Thu, Feb 24, 2022 at 05:11:44PM +0200, Maxim Mikityanskiy wrote:
> > > > @@ -7798,6 +7916,14 @@ xdp_func_proto(enum bpf_func_id func_id, const
> > > struct bpf_prog *prog)
> > > >             return &bpf_tcp_check_syncookie_proto;
> > > >     case BPF_FUNC_tcp_gen_syncookie:
> > > >             return &bpf_tcp_gen_syncookie_proto;
> > > > +   case BPF_FUNC_tcp_raw_gen_syncookie_ipv4:
> > > > +           return &bpf_tcp_raw_gen_syncookie_ipv4_proto;
> > > > +   case BPF_FUNC_tcp_raw_gen_syncookie_ipv6:
> > > > +           return &bpf_tcp_raw_gen_syncookie_ipv6_proto;
> > > > +   case BPF_FUNC_tcp_raw_check_syncookie_ipv4:
> > > > +           return &bpf_tcp_raw_check_syncookie_ipv4_proto;
> > > > +   case BPF_FUNC_tcp_raw_check_syncookie_ipv6:
> > > > +           return &bpf_tcp_raw_check_syncookie_ipv6_proto;
> > > >  #endif
> > >
> > > I understand that the main use case for new helpers is XDP specific,
> > > but why limit them to XDP?
> > > The feature looks generic and applicable to skb too.
> >
> > That sounds like an extra feature, rather than a limitation. That's out
> > of scope of what I planned to do.
> >
> > Besides, it sounds kind of useless to me, because the intention of the
> > new helpers is to accelerate synproxy, and I doubt BPF over SKBs will
> > accelerate anything. Maybe someone else has another use case for these
> > helpers and SKBs - in that case I leave the opportunity to add this
> > feature up to them.
> 
> This patchset will not be accepted until the feature is generalized
> to both xdp and skb and tested for both.
> "I dont have a use case for it" is not an excuse to narrow down the scope.

I'm not narrowing down the scope. It was defined from the very
beginning: accelerating synproxy with XDP. Asking me to add SKB support
is extending the scope and making me develop extra things.

It's a well-known fact that features aren't added to the kernel if there
is no user. Sometimes, features without users (or with few users) are
even removed. Could you elaborate why you require me to develop a
feature that no one is going to use?

In my opinion, the whole review process of this series has many
unhealthy points:

1. I'm constantly requested to increase the scope.

1.1. Split the helpers not related to the feature.

1.2. Add new functionality to the verifier to accept memory regions of
fixed size.

1.3. Add support for SKB.

2. I'm requested to rewrite the same code multiple times, every time in
a new way.

2.1. I had to rewrite the sample into a selftest, then into a different
kind of a selftest. It's not obvious that standalone selftests are
deprecated (am I blind, or is it not documented anywhere?), there are a
lot of such tests already existing. Instead of saying it from the
beginning that the test must use the test_progs runner, you waited until
I implement a standalone one.

3. I receive comments on old code that passed a few iterations of the
review.

3.1. SKB support was never part of the feature, and the series passed
two iterations, but not the third.

3.2. Standalone selftest was OK in v2, but suddenly got unacceptable in
v3.

Patch

diff --git a/include/net/tcp.h b/include/net/tcp.h
index eff2487d972d..0af13663ae73 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -432,6 +432,7 @@  u16 tcp_v4_get_syncookie(struct sock *sk, struct iphdr *iph,
 			 struct tcphdr *th, u32 *cookie);
 u16 tcp_v6_get_syncookie(struct sock *sk, struct ipv6hdr *iph,
 			 struct tcphdr *th, u32 *cookie);
+u16 tcp_parse_mss_option(const struct tcphdr *th, u16 user_mss);
 u16 tcp_get_syncookie_mss(struct request_sock_ops *rsk_ops,
 			  const struct tcp_request_sock_ops *af_ops,
 			  struct sock *sk, struct tcphdr *th);
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 1b933454bbb5..a9a56d555cfb 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -5088,6 +5088,92 @@  union bpf_attr {
  *	Return
  *		0 on success, or a negative error in case of failure. On error
  *		*dst* buffer is zeroed out.
+ *
+ * s64 bpf_tcp_raw_gen_syncookie_ipv4(struct iphdr *iph, struct tcphdr *th, u32 th_len)
+ *	Description
+ *		Try to issue a SYN cookie for the packet with corresponding
+ *		IPv4/TCP headers, *iph* and *th*, without depending on a
+ *		listening socket.
+ *
+ *		*iph* points to the IPv4 header.
+ *
+ *		*th* points to the start of the TCP header, while *th_len*
+ *		contains the length of the TCP header (at least
+ *		**sizeof**\ (**struct tcphdr**)).
+ *	Return
+ *		On success, lower 32 bits hold the generated SYN cookie in
+ *		followed by 16 bits which hold the MSS value for that cookie,
+ *		and the top 16 bits are unused.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EINVAL** if *th_len* is invalid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ * s64 bpf_tcp_raw_gen_syncookie_ipv6(struct ipv6hdr *iph, struct tcphdr *th, u32 th_len)
+ *	Description
+ *		Try to issue a SYN cookie for the packet with corresponding
+ *		IPv6/TCP headers, *iph* and *th*, without depending on a
+ *		listening socket.
+ *
+ *		*iph* points to the IPv6 header.
+ *
+ *		*th* points to the start of the TCP header, while *th_len*
+ *		contains the length of the TCP header (at least
+ *		**sizeof**\ (**struct tcphdr**)).
+ *	Return
+ *		On success, lower 32 bits hold the generated SYN cookie in
+ *		followed by 16 bits which hold the MSS value for that cookie,
+ *		and the top 16 bits are unused.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EINVAL** if *th_len* is invalid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ *		**-EPROTONOSUPPORT** if CONFIG_IPV6 is not builtin.
+ *
+ * int bpf_tcp_raw_check_syncookie_ipv4(struct iphdr *iph, struct tcphdr *th)
+ *	Description
+ *		Check whether *iph* and *th* contain a valid SYN cookie ACK
+ *		without depending on a listening socket.
+ *
+ *		*iph* points to the IPv4 header.
+ *
+ *		*th* points to the TCP header.
+ *	Return
+ *		0 if *iph* and *th* are a valid SYN cookie ACK.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EACCES** if the SYN cookie is not valid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ * int bpf_tcp_raw_check_syncookie_ipv6(struct ipv6hdr *iph, struct tcphdr *th)
+ *	Description
+ *		Check whether *iph* and *th* contain a valid SYN cookie ACK
+ *		without depending on a listening socket.
+ *
+ *		*iph* points to the IPv6 header.
+ *
+ *		*th* points to the TCP header.
+ *	Return
+ *		0 if *iph* and *th* are a valid SYN cookie ACK.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EACCES** if the SYN cookie is not valid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ *		**-EPROTONOSUPPORT** if CONFIG_IPV6 is not builtin.
  */
 #define __BPF_FUNC_MAPPER(FN)		\
 	FN(unspec),			\
@@ -5282,6 +5368,10 @@  union bpf_attr {
 	FN(xdp_load_bytes),		\
 	FN(xdp_store_bytes),		\
 	FN(copy_from_user_task),	\
+	FN(tcp_raw_gen_syncookie_ipv4),	\
+	FN(tcp_raw_gen_syncookie_ipv6),	\
+	FN(tcp_raw_check_syncookie_ipv4),	\
+	FN(tcp_raw_check_syncookie_ipv6),	\
 	/* */
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper
diff --git a/net/core/filter.c b/net/core/filter.c
index 0edbfdc8cb24..76426a87225c 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7388,6 +7388,124 @@  static const struct bpf_func_proto bpf_sock_ops_reserve_hdr_opt_proto = {
 	.arg3_type	= ARG_ANYTHING,
 };
 
+BPF_CALL_3(bpf_tcp_raw_gen_syncookie_ipv4, struct iphdr *, iph,
+	   struct tcphdr *, th, u32, th_len)
+{
+#ifdef CONFIG_SYN_COOKIES
+	u32 cookie;
+	u16 mss;
+
+	if (unlikely(th_len < sizeof(*th) || th_len != th->doff * 4))
+		return -EINVAL;
+
+	mss = tcp_parse_mss_option(th, 0) ?: TCP_MSS_DEFAULT;
+	cookie = __cookie_v4_init_sequence(iph, th, &mss);
+
+	return cookie | ((u64)mss << 32);
+#else
+	return -EOPNOTSUPP;
+#endif /* CONFIG_SYN_COOKIES */
+}
+
+static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv4_proto = {
+	.func		= bpf_tcp_raw_gen_syncookie_ipv4,
+	.gpl_only	= true, /* __cookie_v4_init_sequence() is GPL */
+	.pkt_access	= true,
+	.ret_type	= RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_MEM,
+	.arg1_size	= sizeof(struct iphdr),
+	.arg2_type	= ARG_PTR_TO_MEM,
+	.arg3_type	= ARG_CONST_SIZE,
+};
+
+BPF_CALL_3(bpf_tcp_raw_gen_syncookie_ipv6, struct ipv6hdr *, iph,
+	   struct tcphdr *, th, u32, th_len)
+{
+#ifndef CONFIG_SYN_COOKIES
+	return -EOPNOTSUPP;
+#elif !IS_BUILTIN(CONFIG_IPV6)
+	return -EPROTONOSUPPORT;
+#else
+	const u16 mss_clamp = IPV6_MIN_MTU - sizeof(struct tcphdr) -
+		sizeof(struct ipv6hdr);
+	u32 cookie;
+	u16 mss;
+
+	if (unlikely(th_len < sizeof(*th) || th_len != th->doff * 4))
+		return -EINVAL;
+
+	mss = tcp_parse_mss_option(th, 0) ?: mss_clamp;
+	cookie = __cookie_v6_init_sequence(iph, th, &mss);
+
+	return cookie | ((u64)mss << 32);
+#endif
+}
+
+static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv6_proto = {
+	.func		= bpf_tcp_raw_gen_syncookie_ipv6,
+	.gpl_only	= true, /* __cookie_v6_init_sequence() is GPL */
+	.pkt_access	= true,
+	.ret_type	= RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_MEM,
+	.arg1_size	= sizeof(struct ipv6hdr),
+	.arg2_type	= ARG_PTR_TO_MEM,
+	.arg3_type	= ARG_CONST_SIZE,
+};
+
+BPF_CALL_2(bpf_tcp_raw_check_syncookie_ipv4, struct iphdr *, iph,
+	   struct tcphdr *, th)
+{
+#ifdef CONFIG_SYN_COOKIES
+	u32 cookie = ntohl(th->ack_seq) - 1;
+
+	if (__cookie_v4_check(iph, th, cookie) > 0)
+		return 0;
+
+	return -EACCES;
+#else
+	return -EOPNOTSUPP;
+#endif
+}
+
+static const struct bpf_func_proto bpf_tcp_raw_check_syncookie_ipv4_proto = {
+	.func		= bpf_tcp_raw_check_syncookie_ipv4,
+	.gpl_only	= true, /* __cookie_v4_check is GPL */
+	.pkt_access	= true,
+	.ret_type	= RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_MEM,
+	.arg1_size	= sizeof(struct iphdr),
+	.arg2_type	= ARG_PTR_TO_MEM,
+	.arg2_size	= sizeof(struct tcphdr),
+};
+
+BPF_CALL_2(bpf_tcp_raw_check_syncookie_ipv6, struct ipv6hdr *, iph,
+	   struct tcphdr *, th)
+{
+#ifndef CONFIG_SYN_COOKIES
+	return -EOPNOTSUPP;
+#elif !IS_BUILTIN(CONFIG_IPV6)
+	return -EPROTONOSUPPORT;
+#else
+	u32 cookie = ntohl(th->ack_seq) - 1;
+
+	if (__cookie_v6_check(iph, th, cookie) > 0)
+		return 0;
+
+	return -EACCES;
+#endif
+}
+
+static const struct bpf_func_proto bpf_tcp_raw_check_syncookie_ipv6_proto = {
+	.func		= bpf_tcp_raw_check_syncookie_ipv6,
+	.gpl_only	= true, /* __cookie_v6_check is GPL */
+	.pkt_access	= true,
+	.ret_type	= RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_MEM,
+	.arg1_size	= sizeof(struct ipv6hdr),
+	.arg2_type	= ARG_PTR_TO_MEM,
+	.arg2_size	= sizeof(struct tcphdr),
+};
+
 #endif /* CONFIG_INET */
 
 bool bpf_helper_changes_pkt_data(void *func)
@@ -7798,6 +7916,14 @@  xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
 		return &bpf_tcp_check_syncookie_proto;
 	case BPF_FUNC_tcp_gen_syncookie:
 		return &bpf_tcp_gen_syncookie_proto;
+	case BPF_FUNC_tcp_raw_gen_syncookie_ipv4:
+		return &bpf_tcp_raw_gen_syncookie_ipv4_proto;
+	case BPF_FUNC_tcp_raw_gen_syncookie_ipv6:
+		return &bpf_tcp_raw_gen_syncookie_ipv6_proto;
+	case BPF_FUNC_tcp_raw_check_syncookie_ipv4:
+		return &bpf_tcp_raw_check_syncookie_ipv4_proto;
+	case BPF_FUNC_tcp_raw_check_syncookie_ipv6:
+		return &bpf_tcp_raw_check_syncookie_ipv6_proto;
 #endif
 	default:
 		return bpf_sk_base_func_proto(func_id);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 92e65d56dc2c..ea8a78d52e25 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3963,7 +3963,7 @@  static bool smc_parse_options(const struct tcphdr *th,
 /* Try to parse the MSS option from the TCP header. Return 0 on failure, clamped
  * value on success.
  */
-static u16 tcp_parse_mss_option(const struct tcphdr *th, u16 user_mss)
+u16 tcp_parse_mss_option(const struct tcphdr *th, u16 user_mss)
 {
 	const unsigned char *ptr = (const unsigned char *)(th + 1);
 	int length = (th->doff * 4) - sizeof(struct tcphdr);
@@ -4002,6 +4002,7 @@  static u16 tcp_parse_mss_option(const struct tcphdr *th, u16 user_mss)
 	}
 	return mss;
 }
+EXPORT_SYMBOL_GPL(tcp_parse_mss_option);
 
 /* Look for tcp options. Normally only called on SYN and SYNACK packets.
  * But, this can also be called on packets in the established flow when
diff --git a/scripts/bpf_doc.py b/scripts/bpf_doc.py
index 096625242475..3d0b65e6dea7 100755
--- a/scripts/bpf_doc.py
+++ b/scripts/bpf_doc.py
@@ -633,6 +633,8 @@  class PrinterHelpers(Printer):
             'struct socket',
             'struct file',
             'struct bpf_timer',
+            'struct iphdr',
+            'struct ipv6hdr',
     ]
     known_types = {
             '...',
@@ -682,6 +684,8 @@  class PrinterHelpers(Printer):
             'struct socket',
             'struct file',
             'struct bpf_timer',
+            'struct iphdr',
+            'struct ipv6hdr',
     }
     mapped_types = {
             'u8': '__u8',
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 1b933454bbb5..a9a56d555cfb 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -5088,6 +5088,92 @@  union bpf_attr {
  *	Return
  *		0 on success, or a negative error in case of failure. On error
  *		*dst* buffer is zeroed out.
+ *
+ * s64 bpf_tcp_raw_gen_syncookie_ipv4(struct iphdr *iph, struct tcphdr *th, u32 th_len)
+ *	Description
+ *		Try to issue a SYN cookie for the packet with corresponding
+ *		IPv4/TCP headers, *iph* and *th*, without depending on a
+ *		listening socket.
+ *
+ *		*iph* points to the IPv4 header.
+ *
+ *		*th* points to the start of the TCP header, while *th_len*
+ *		contains the length of the TCP header (at least
+ *		**sizeof**\ (**struct tcphdr**)).
+ *	Return
+ *		On success, lower 32 bits hold the generated SYN cookie in
+ *		followed by 16 bits which hold the MSS value for that cookie,
+ *		and the top 16 bits are unused.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EINVAL** if *th_len* is invalid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ * s64 bpf_tcp_raw_gen_syncookie_ipv6(struct ipv6hdr *iph, struct tcphdr *th, u32 th_len)
+ *	Description
+ *		Try to issue a SYN cookie for the packet with corresponding
+ *		IPv6/TCP headers, *iph* and *th*, without depending on a
+ *		listening socket.
+ *
+ *		*iph* points to the IPv6 header.
+ *
+ *		*th* points to the start of the TCP header, while *th_len*
+ *		contains the length of the TCP header (at least
+ *		**sizeof**\ (**struct tcphdr**)).
+ *	Return
+ *		On success, lower 32 bits hold the generated SYN cookie in
+ *		followed by 16 bits which hold the MSS value for that cookie,
+ *		and the top 16 bits are unused.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EINVAL** if *th_len* is invalid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ *		**-EPROTONOSUPPORT** if CONFIG_IPV6 is not builtin.
+ *
+ * int bpf_tcp_raw_check_syncookie_ipv4(struct iphdr *iph, struct tcphdr *th)
+ *	Description
+ *		Check whether *iph* and *th* contain a valid SYN cookie ACK
+ *		without depending on a listening socket.
+ *
+ *		*iph* points to the IPv4 header.
+ *
+ *		*th* points to the TCP header.
+ *	Return
+ *		0 if *iph* and *th* are a valid SYN cookie ACK.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EACCES** if the SYN cookie is not valid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ * int bpf_tcp_raw_check_syncookie_ipv6(struct ipv6hdr *iph, struct tcphdr *th)
+ *	Description
+ *		Check whether *iph* and *th* contain a valid SYN cookie ACK
+ *		without depending on a listening socket.
+ *
+ *		*iph* points to the IPv6 header.
+ *
+ *		*th* points to the TCP header.
+ *	Return
+ *		0 if *iph* and *th* are a valid SYN cookie ACK.
+ *
+ *		On failure, the returned value is one of the following:
+ *
+ *		**-EACCES** if the SYN cookie is not valid.
+ *
+ *		**-EOPNOTSUPP** if the kernel configuration does not enable SYN
+ *		cookies (CONFIG_SYN_COOKIES is off).
+ *
+ *		**-EPROTONOSUPPORT** if CONFIG_IPV6 is not builtin.
  */
 #define __BPF_FUNC_MAPPER(FN)		\
 	FN(unspec),			\
@@ -5282,6 +5368,10 @@  union bpf_attr {
 	FN(xdp_load_bytes),		\
 	FN(xdp_store_bytes),		\
 	FN(copy_from_user_task),	\
+	FN(tcp_raw_gen_syncookie_ipv4),	\
+	FN(tcp_raw_gen_syncookie_ipv6),	\
+	FN(tcp_raw_check_syncookie_ipv4),	\
+	FN(tcp_raw_check_syncookie_ipv6),	\
 	/* */
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper