* [PATCH] Clock-independent TCP ISN generation @ 2019-09-03 5:06 Cyrus Sh 2019-09-03 7:41 ` Eric Dumazet 2019-09-03 7:45 ` kbuild test robot 0 siblings, 2 replies; 14+ messages in thread From: Cyrus Sh @ 2019-09-03 5:06 UTC (permalink / raw) To: davem; +Cc: shiraz.saleem, jgg, arnd, arnd, netdev, sirus This patch addresses the privacy issue of TCP ISN generation in Linux kernel. Currently an adversary can deanonymize a user behind an anonymity network by inducing a load pattern on the target machine and correlating its clock skew with the pattern. Since the kernel adds a clock-based counter to generated ISNs, the adversary can observe SYN packets with similar IP and port numbers to find out the clock skew of the target machine and this can help them identify the user. To resolve this problem I have changed the related function to generate the initial sequence numbers randomly and independent from the cpu clock. This feature is controlled by a new sysctl option called "tcp_random_isn" which I've added to the kernel. Once enabled the initial sequence numbers are guaranteed to be generated independently from each other and from the hardware clock of the machine. If the option is off, ISNs are generated as before. To get more information about this patch and its effectiveness you can refer to my post here: https://bitguard.wordpress.com/?p=982 and to see a discussion about the issue you can read this: https://trac.torproject.org/projects/tor/ticket/16659 Signed-off-by: Sirus Shahini <sirus.shahini@gmail.com> --- include/net/tcp.h | 1 + include/uapi/linux/sysctl.h | 1 + kernel/sysctl_binary.c | 1 + net/core/secure_seq.c | 24 +++++++++++++++++++++++- net/ipv4/sysctl_net_ipv4.c | 7 +++++++ net/ipv4/tcp_input.c | 1 + 6 files changed, 34 insertions(+), 1 deletion(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 81e8ade..4ad1bbf 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -241,6 +241,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo); /* sysctl variables for tcp */ extern int sysctl_tcp_max_orphans; +extern int sysctl_tcp_random_isn; extern long sysctl_tcp_mem[3]; #define TCP_RACK_LOSS_DETECTION 0x1 /* Use RACK to detect losses */ diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h index 87aa2a6..ba8927e 100644 --- a/include/uapi/linux/sysctl.h +++ b/include/uapi/linux/sysctl.h @@ -426,6 +426,7 @@ enum NET_TCP_ALLOWED_CONG_CONTROL=123, NET_TCP_MAX_SSTHRESH=124, NET_TCP_FRTO_RESPONSE=125, + NET_IPV4_TCP_RANDOM_ISN=126, }; enum { diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c index 73c1320..0faf7d4 100644 --- a/kernel/sysctl_binary.c +++ b/kernel/sysctl_binary.c @@ -332,6 +332,7 @@ static const struct bin_table bin_net_ipv4_netfilter_table[] = { }; static const struct bin_table bin_net_ipv4_table[] = { + {CTL_INT, NET_IPV4_TCP_RANDOM_ISN "tcp_random_isn"} {CTL_INT, NET_IPV4_FORWARD, "ip_forward" }, { CTL_DIR, NET_IPV4_CONF, "conf", bin_net_ipv4_conf_table }, diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c index 7b6b1d2..b644bbe 100644 --- a/net/core/secure_seq.c +++ b/net/core/secure_seq.c @@ -22,6 +22,7 @@ static siphash_key_t net_secret __read_mostly; static siphash_key_t ts_secret __read_mostly; +static siphash_key_t last_secret = {{0,0}} ; static __always_inline void net_secret_init(void) { @@ -134,8 +135,29 @@ u32 secure_tcp_seq(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport) { u32 hash; - + u32 temp; + net_secret_init(); + + if (sysctl_tcp_random_isn){ + if (!last_secret.key[0] && !last_secret.key[1]){ + memcpy(&last_secret,&net_secret,sizeof(last_secret)); + + }else{ + temp = *((u32*)&(net_secret.key[0])); + temp >>= 8; + last_secret.key[0]+=temp; + temp = *((u32*)&(net_secret.key[1])); + temp >>= 8; + last_secret.key[1]+=temp; + } + hash = siphash_3u32((__force u32)saddr, (__force u32)daddr, + (__force u32)sport << 16 | (__force u32)dport, + &last_secret); + return hash; + } + + hash = siphash_3u32((__force u32)saddr, (__force u32)daddr, (__force u32)sport << 16 | (__force u32)dport, &net_secret); diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c index 0b980e8..74b2b6a 100644 --- a/net/ipv4/sysctl_net_ipv4.c +++ b/net/ipv4/sysctl_net_ipv4.c @@ -479,6 +479,13 @@ static int proc_fib_multipath_hash_policy(struct ctl_table *table, int write, static struct ctl_table ipv4_table[] = { { + .procname = "tcp_random_isn", + .data = &sysctl_tcp_random_isn, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec + }, + { .procname = "tcp_max_orphans", .data = &sysctl_tcp_max_orphans, .maxlen = sizeof(int), diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index c21e8a2..c6b4ebf 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -80,6 +80,7 @@ #include <linux/jump_label_ratelimit.h> #include <net/busy_poll.h> +int sysctl_tcp_random_isn __read_mostly = 0; int sysctl_tcp_max_orphans __read_mostly = NR_FILE; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ -- 2.7.4 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh @ 2019-09-03 7:41 ` Eric Dumazet 2019-09-03 15:39 ` Cyrus Sh 2019-09-03 7:45 ` kbuild test robot 1 sibling, 1 reply; 14+ messages in thread From: Eric Dumazet @ 2019-09-03 7:41 UTC (permalink / raw) To: Cyrus Sh, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 7:06 AM, Cyrus Sh wrote: > This patch addresses the privacy issue of TCP ISN generation in Linux > kernel. Currently an adversary can deanonymize a user behind an anonymity > network by inducing a load pattern on the target machine and correlating > its clock skew with the pattern. Since the kernel adds a clock-based > counter to generated ISNs, the adversary can observe SYN packets with > similar IP and port numbers to find out the clock skew of the target > machine and this can help them identify the user. To resolve this problem > I have changed the related function to generate the initial sequence > numbers randomly and independent from the cpu clock. This feature is > controlled by a new sysctl option called "tcp_random_isn" which I've added > to the kernel. Once enabled the initial sequence numbers are guaranteed to > be generated independently from each other and from the hardware clock of > the machine. If the option is off, ISNs are generated as before. To get > more information about this patch and its effectiveness you can refer to my > post here: > https://bitguard.wordpress.com/?p=982 <quote> Firstly it’s unlikely that this happens at all, </quote> Sorry this happens all the time. Some people use very disturbing setups really, and they are not trying to be malicious. Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ? > and to see a discussion about the issue you can read this: > https://trac.torproject.org/projects/tor/ticket/16659 Four years old discussion. Does not seem urgent matter :/ > > Signed-off-by: Sirus Shahini <sirus.shahini@gmail.com> > --- > include/net/tcp.h | 1 + > include/uapi/linux/sysctl.h | 1 + > kernel/sysctl_binary.c | 1 + > net/core/secure_seq.c | 24 +++++++++++++++++++++++- > net/ipv4/sysctl_net_ipv4.c | 7 +++++++ > net/ipv4/tcp_input.c | 1 + > 6 files changed, 34 insertions(+), 1 deletion(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 81e8ade..4ad1bbf 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -241,6 +241,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo); > > /* sysctl variables for tcp */ > extern int sysctl_tcp_max_orphans; > +extern int sysctl_tcp_random_isn; All TCP sysctls are per netns these days. (Look in include/net/netns/ipv4.h ) > extern long sysctl_tcp_mem[3]; > > #define TCP_RACK_LOSS_DETECTION 0x1 /* Use RACK to detect losses */ > diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h > index 87aa2a6..ba8927e 100644 > --- a/include/uapi/linux/sysctl.h > +++ b/include/uapi/linux/sysctl.h > @@ -426,6 +426,7 @@ enum > NET_TCP_ALLOWED_CONG_CONTROL=123, > NET_TCP_MAX_SSTHRESH=124, > NET_TCP_FRTO_RESPONSE=125, > + NET_IPV4_TCP_RANDOM_ISN=126, Nope, we do not add new sysctls there anymore. Everybody should now have /proc files to tune the values. > }; > > enum { > diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c > index 73c1320..0faf7d4 100644 > --- a/kernel/sysctl_binary.c > +++ b/kernel/sysctl_binary.c > @@ -332,6 +332,7 @@ static const struct bin_table bin_net_ipv4_netfilter_table[] = { > }; > > static const struct bin_table bin_net_ipv4_table[] = { > + {CTL_INT, NET_IPV4_TCP_RANDOM_ISN "tcp_random_isn"} Same remark. We no longer add stuff there. > {CTL_INT, NET_IPV4_FORWARD, "ip_forward" }, > > { CTL_DIR, NET_IPV4_CONF, "conf", bin_net_ipv4_conf_table }, > diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c > index 7b6b1d2..b644bbe 100644 > --- a/net/core/secure_seq.c > +++ b/net/core/secure_seq.c > @@ -22,6 +22,7 @@ > > static siphash_key_t net_secret __read_mostly; > static siphash_key_t ts_secret __read_mostly; > +static siphash_key_t last_secret = {{0,0}} ; > > static __always_inline void net_secret_init(void) > { > @@ -134,8 +135,29 @@ u32 secure_tcp_seq(__be32 saddr, __be32 daddr, > __be16 sport, __be16 dport) > { > u32 hash; > - > + u32 temp; > + > net_secret_init(); > + > + if (sysctl_tcp_random_isn){ > + if (!last_secret.key[0] && !last_secret.key[1]){ > + memcpy(&last_secret,&net_secret,sizeof(last_secret)); > + > + }else{ Check your patch using scripts/checkpatch.pl All these missing spaces should be spotted. > + temp = *((u32*)&(net_secret.key[0])); > + temp >>= 8; > + last_secret.key[0]+=temp; > + temp = *((u32*)&(net_secret.key[1])); > + temp >>= 8; > + last_secret.key[1]+=temp; Why not simply use an official random generator, instead of these convoluted and not SMP safe attempts ? Check drivers/char/random.c for officially maintained generators. > + } > + hash = siphash_3u32((__force u32)saddr, (__force u32)daddr, > + (__force u32)sport << 16 | (__force u32)dport, > + &last_secret); > + return hash; > + } > + > + > hash = siphash_3u32((__force u32)saddr, (__force u32)daddr, > (__force u32)sport << 16 | (__force u32)dport, > &net_secret); ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 7:41 ` Eric Dumazet @ 2019-09-03 15:39 ` Cyrus Sh 2019-09-03 15:59 ` Eric Dumazet 0 siblings, 1 reply; 14+ messages in thread From: Cyrus Sh @ 2019-09-03 15:39 UTC (permalink / raw) To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 1:41 AM, Eric Dumazet wrote: > Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ? Can you provide any reference to somewhere that explains these firewall rules and how to exactly use them to prevent this specific type of attack? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 15:39 ` Cyrus Sh @ 2019-09-03 15:59 ` Eric Dumazet 2019-09-03 16:06 ` Cyrus Sh 2019-09-03 16:12 ` Cyrus Sh 0 siblings, 2 replies; 14+ messages in thread From: Eric Dumazet @ 2019-09-03 15:59 UTC (permalink / raw) To: Cyrus Sh, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 5:39 PM, Cyrus Sh wrote: > > > On 9/3/19 1:41 AM, Eric Dumazet wrote: >> Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ? > > Can you provide any reference to somewhere that explains these firewall rules > and how to exactly use them to prevent this specific type of attack? > You could add a random delay to all SYN packets, if you believe your host has clock skews. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 15:59 ` Eric Dumazet @ 2019-09-03 16:06 ` Cyrus Sh 2019-09-03 16:17 ` Eric Dumazet 2019-09-03 22:43 ` David Miller 2019-09-03 16:12 ` Cyrus Sh 1 sibling, 2 replies; 14+ messages in thread From: Cyrus Sh @ 2019-09-03 16:06 UTC (permalink / raw) To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 9:59 AM, Eric Dumazet wrote: > > You could add a random delay to all SYN packets, if you believe your host has clock skews. In theory yes, but again do you know any practical example with tested applications and the list of the rules? I'm interested to see an actual example that somebody has carried out and observed its results. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:06 ` Cyrus Sh @ 2019-09-03 16:17 ` Eric Dumazet 2019-09-03 16:27 ` Cyrus Sh 2019-09-03 22:43 ` David Miller 1 sibling, 1 reply; 14+ messages in thread From: Eric Dumazet @ 2019-09-03 16:17 UTC (permalink / raw) To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 6:06 PM, Cyrus Sh wrote: > > > On 9/3/19 9:59 AM, Eric Dumazet wrote: >> >> You could add a random delay to all SYN packets, if you believe your host has clock skews. > > In theory yes, but again do you know any practical example with tested > applications and the list of the rules? I'm interested to see an actual example > that somebody has carried out and observed its results. > Do you have a real program showing us how this clock skew can be used practically ? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:17 ` Eric Dumazet @ 2019-09-03 16:27 ` Cyrus Sh 2019-09-03 16:42 ` Eric Dumazet 2019-09-03 22:45 ` David Miller 0 siblings, 2 replies; 14+ messages in thread From: Cyrus Sh @ 2019-09-03 16:27 UTC (permalink / raw) To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 10:17 AM, Eric Dumazet wrote: > Do you have a real program showing us how this clock skew can be used practically ? This is a well studied issue. You can take a look at this presentation as an example: http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf > You will have to convince people at IETF and get a proper RFC No I won't. A lot of these standards have been written at a time that anonymity networks were not of big importance. Now that they are, we try to lessen the negative impacts of some RFC deficiencies by improving the implementation. It's up to you whether to want to keep using a problematic code that may endanger users or want to do something about it since we won't insist on having a patch accepted. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:27 ` Cyrus Sh @ 2019-09-03 16:42 ` Eric Dumazet 2019-09-03 22:45 ` David Miller 1 sibling, 0 replies; 14+ messages in thread From: Eric Dumazet @ 2019-09-03 16:42 UTC (permalink / raw) To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 6:27 PM, Cyrus Sh wrote: > > > On 9/3/19 10:17 AM, Eric Dumazet wrote: > >> Do you have a real program showing us how this clock skew can be used practically ? > This is a well studied issue. You can take a look at this presentation as an > example: > http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf 2008 ? Really ? I do not want an example, I want a proof that current systems are exhibiting all the needed behavior. I do not have time to spend hours reading old stuff based on old architectures. > >> You will have to convince people at IETF and get a proper RFC > No I won't. A lot of these standards have been written at a time that anonymity > networks were not of big importance. Now that they are, we try to lessen the > negative impacts of some RFC deficiencies by improving the implementation. It's > up to you whether to want to keep using a problematic code that may endanger > users or want to do something about it since we won't insist on having a patch > accepted. > Then this is the end. linux wont change something as fundamental without proper feedback from the community. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:27 ` Cyrus Sh 2019-09-03 16:42 ` Eric Dumazet @ 2019-09-03 22:45 ` David Miller 2019-09-04 0:45 ` Cyrus Sh 1 sibling, 1 reply; 14+ messages in thread From: David Miller @ 2019-09-03 22:45 UTC (permalink / raw) To: sirus.shahini; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus From: Cyrus Sh <sirus.shahini@gmail.com> Date: Tue, 3 Sep 2019 10:27:41 -0600 > It's up to you whether to want to keep using a problematic code that > may endanger users or want to do something about it since we won't > insist on having a patch accepted. At least our problematic code, unlike your patch, compiles. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 22:45 ` David Miller @ 2019-09-04 0:45 ` Cyrus Sh 0 siblings, 0 replies; 14+ messages in thread From: Cyrus Sh @ 2019-09-04 0:45 UTC (permalink / raw) To: David Miller; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 4:45 PM, David Miller wrote: > At least our problematic code, unlike your patch, compiles. I obviously compiled and tested the code before sending along and this should be easy to understand. Even I published the results in the link that I mentioned in the initial message. Now I'm not sure what you're doing that you're unable to compile the code. What compilation error message do you get? This patch has been written for kernel 5.3-rc7. Further the reason that I asked for a specific practical example was that I wanted to actually test different techniques and see their effectiveness. (Again should be easy to understand, I don't know why it's not for you and why it made you upset) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:06 ` Cyrus Sh 2019-09-03 16:17 ` Eric Dumazet @ 2019-09-03 22:43 ` David Miller 1 sibling, 0 replies; 14+ messages in thread From: David Miller @ 2019-09-03 22:43 UTC (permalink / raw) To: sirus.shahini; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus From: Cyrus Sh <sirus.shahini@gmail.com> Date: Tue, 3 Sep 2019 10:06:03 -0600 > On 9/3/19 9:59 AM, Eric Dumazet wrote: >> >> You could add a random delay to all SYN packets, if you believe your host has clock skews. > > In theory yes, but again do you know any practical example with tested > applications and the list of the rules? I'm interested to see an actual example > that somebody has carried out and observed its results. That's ironic that you're asking for specific and "practical" examples when you submitted a kernel patch that doesn't even compile. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 15:59 ` Eric Dumazet 2019-09-03 16:06 ` Cyrus Sh @ 2019-09-03 16:12 ` Cyrus Sh 2019-09-03 16:16 ` Eric Dumazet 1 sibling, 1 reply; 14+ messages in thread From: Cyrus Sh @ 2019-09-03 16:12 UTC (permalink / raw) To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 9:59 AM, Eric Dumazet wrote: > You could add a random delay to all SYN packets, if you believe your host has clock skews. And by the way adding delays has its own performance penalties. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 16:12 ` Cyrus Sh @ 2019-09-03 16:16 ` Eric Dumazet 0 siblings, 0 replies; 14+ messages in thread From: Eric Dumazet @ 2019-09-03 16:16 UTC (permalink / raw) To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus On 9/3/19 6:12 PM, Cyrus Sh wrote: > > > On 9/3/19 9:59 AM, Eric Dumazet wrote: > >> You could add a random delay to all SYN packets, if you believe your host has clock skews. > > And by the way adding delays has its own performance penalties. > You understand your patch has been rejected, right ? You will have to convince people at IETF and get a proper RFC before I even look at the idea. BTW, sending a patch only dealing with IPv4 is also not a good thing. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] Clock-independent TCP ISN generation 2019-09-03 5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh 2019-09-03 7:41 ` Eric Dumazet @ 2019-09-03 7:45 ` kbuild test robot 1 sibling, 0 replies; 14+ messages in thread From: kbuild test robot @ 2019-09-03 7:45 UTC (permalink / raw) To: Cyrus Sh; +Cc: kbuild-all, davem, shiraz.saleem, jgg, arnd, netdev, sirus [-- Attachment #1: Type: text/plain, Size: 7349 bytes --] Hi Cyrus, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc7 next-20190902] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyrus-Sh/Clock-independent-TCP-ISN-generation/20190903-131719 config: x86_64-randconfig-e003-201935 (attached as .config) compiler: gcc-7 (Debian 7.4.0-11) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp@intel.com> All errors (new ones prefixed by >>): >> kernel/sysctl_binary.c:335:42: error: expected '}' before string constant {CTL_INT, NET_IPV4_TCP_RANDOM_ISN "tcp_random_isn"} ^~~~~~~~~~~~~~~~ >> kernel/sysctl_binary.c:336:2: error: expected '}' before '{' token {CTL_INT, NET_IPV4_FORWARD, "ip_forward" }, ^ vim +335 kernel/sysctl_binary.c 333 334 static const struct bin_table bin_net_ipv4_table[] = { > 335 {CTL_INT, NET_IPV4_TCP_RANDOM_ISN "tcp_random_isn"} > 336 {CTL_INT, NET_IPV4_FORWARD, "ip_forward" }, 337 338 { CTL_DIR, NET_IPV4_CONF, "conf", bin_net_ipv4_conf_table }, 339 { CTL_DIR, NET_IPV4_NEIGH, "neigh", bin_net_neigh_table }, 340 { CTL_DIR, NET_IPV4_ROUTE, "route", bin_net_ipv4_route_table }, 341 /* NET_IPV4_FIB_HASH unused */ 342 { CTL_DIR, NET_IPV4_NETFILTER, "netfilter", bin_net_ipv4_netfilter_table }, 343 344 { CTL_INT, NET_IPV4_TCP_TIMESTAMPS, "tcp_timestamps" }, 345 { CTL_INT, NET_IPV4_TCP_WINDOW_SCALING, "tcp_window_scaling" }, 346 { CTL_INT, NET_IPV4_TCP_SACK, "tcp_sack" }, 347 { CTL_INT, NET_IPV4_TCP_RETRANS_COLLAPSE, "tcp_retrans_collapse" }, 348 { CTL_INT, NET_IPV4_DEFAULT_TTL, "ip_default_ttl" }, 349 /* NET_IPV4_AUTOCONFIG unused */ 350 { CTL_INT, NET_IPV4_NO_PMTU_DISC, "ip_no_pmtu_disc" }, 351 { CTL_INT, NET_IPV4_NONLOCAL_BIND, "ip_nonlocal_bind" }, 352 { CTL_INT, NET_IPV4_TCP_SYN_RETRIES, "tcp_syn_retries" }, 353 { CTL_INT, NET_TCP_SYNACK_RETRIES, "tcp_synack_retries" }, 354 { CTL_INT, NET_TCP_MAX_ORPHANS, "tcp_max_orphans" }, 355 { CTL_INT, NET_TCP_MAX_TW_BUCKETS, "tcp_max_tw_buckets" }, 356 { CTL_INT, NET_IPV4_DYNADDR, "ip_dynaddr" }, 357 { CTL_INT, NET_IPV4_TCP_KEEPALIVE_TIME, "tcp_keepalive_time" }, 358 { CTL_INT, NET_IPV4_TCP_KEEPALIVE_PROBES, "tcp_keepalive_probes" }, 359 { CTL_INT, NET_IPV4_TCP_KEEPALIVE_INTVL, "tcp_keepalive_intvl" }, 360 { CTL_INT, NET_IPV4_TCP_RETRIES1, "tcp_retries1" }, 361 { CTL_INT, NET_IPV4_TCP_RETRIES2, "tcp_retries2" }, 362 { CTL_INT, NET_IPV4_TCP_FIN_TIMEOUT, "tcp_fin_timeout" }, 363 { CTL_INT, NET_TCP_SYNCOOKIES, "tcp_syncookies" }, 364 { CTL_INT, NET_TCP_TW_RECYCLE, "tcp_tw_recycle" }, 365 { CTL_INT, NET_TCP_ABORT_ON_OVERFLOW, "tcp_abort_on_overflow" }, 366 { CTL_INT, NET_TCP_STDURG, "tcp_stdurg" }, 367 { CTL_INT, NET_TCP_RFC1337, "tcp_rfc1337" }, 368 { CTL_INT, NET_TCP_MAX_SYN_BACKLOG, "tcp_max_syn_backlog" }, 369 { CTL_INT, NET_IPV4_LOCAL_PORT_RANGE, "ip_local_port_range" }, 370 { CTL_INT, NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships" }, 371 { CTL_INT, NET_IPV4_IGMP_MAX_MSF, "igmp_max_msf" }, 372 { CTL_INT, NET_IPV4_INET_PEER_THRESHOLD, "inet_peer_threshold" }, 373 { CTL_INT, NET_IPV4_INET_PEER_MINTTL, "inet_peer_minttl" }, 374 { CTL_INT, NET_IPV4_INET_PEER_MAXTTL, "inet_peer_maxttl" }, 375 { CTL_INT, NET_IPV4_INET_PEER_GC_MINTIME, "inet_peer_gc_mintime" }, 376 { CTL_INT, NET_IPV4_INET_PEER_GC_MAXTIME, "inet_peer_gc_maxtime" }, 377 { CTL_INT, NET_TCP_ORPHAN_RETRIES, "tcp_orphan_retries" }, 378 { CTL_INT, NET_TCP_FACK, "tcp_fack" }, 379 { CTL_INT, NET_TCP_REORDERING, "tcp_reordering" }, 380 { CTL_INT, NET_TCP_ECN, "tcp_ecn" }, 381 { CTL_INT, NET_TCP_DSACK, "tcp_dsack" }, 382 { CTL_INT, NET_TCP_MEM, "tcp_mem" }, 383 { CTL_INT, NET_TCP_WMEM, "tcp_wmem" }, 384 { CTL_INT, NET_TCP_RMEM, "tcp_rmem" }, 385 { CTL_INT, NET_TCP_APP_WIN, "tcp_app_win" }, 386 { CTL_INT, NET_TCP_ADV_WIN_SCALE, "tcp_adv_win_scale" }, 387 { CTL_INT, NET_TCP_TW_REUSE, "tcp_tw_reuse" }, 388 { CTL_INT, NET_TCP_FRTO, "tcp_frto" }, 389 { CTL_INT, NET_TCP_FRTO_RESPONSE, "tcp_frto_response" }, 390 { CTL_INT, NET_TCP_LOW_LATENCY, "tcp_low_latency" }, 391 { CTL_INT, NET_TCP_NO_METRICS_SAVE, "tcp_no_metrics_save" }, 392 { CTL_INT, NET_TCP_MODERATE_RCVBUF, "tcp_moderate_rcvbuf" }, 393 { CTL_INT, NET_TCP_TSO_WIN_DIVISOR, "tcp_tso_win_divisor" }, 394 { CTL_STR, NET_TCP_CONG_CONTROL, "tcp_congestion_control" }, 395 { CTL_INT, NET_TCP_MTU_PROBING, "tcp_mtu_probing" }, 396 { CTL_INT, NET_TCP_BASE_MSS, "tcp_base_mss" }, 397 { CTL_INT, NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS, "tcp_workaround_signed_windows" }, 398 { CTL_INT, NET_TCP_SLOW_START_AFTER_IDLE, "tcp_slow_start_after_idle" }, 399 { CTL_INT, NET_CIPSOV4_CACHE_ENABLE, "cipso_cache_enable" }, 400 { CTL_INT, NET_CIPSOV4_CACHE_BUCKET_SIZE, "cipso_cache_bucket_size" }, 401 { CTL_INT, NET_CIPSOV4_RBM_OPTFMT, "cipso_rbm_optfmt" }, 402 { CTL_INT, NET_CIPSOV4_RBM_STRICTVALID, "cipso_rbm_strictvalid" }, 403 /* NET_TCP_AVAIL_CONG_CONTROL "tcp_available_congestion_control" no longer used */ 404 { CTL_STR, NET_TCP_ALLOWED_CONG_CONTROL, "tcp_allowed_congestion_control" }, 405 { CTL_INT, NET_TCP_MAX_SSTHRESH, "tcp_max_ssthresh" }, 406 407 { CTL_INT, NET_IPV4_ICMP_ECHO_IGNORE_ALL, "icmp_echo_ignore_all" }, 408 { CTL_INT, NET_IPV4_ICMP_ECHO_IGNORE_BROADCASTS, "icmp_echo_ignore_broadcasts" }, 409 { CTL_INT, NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES, "icmp_ignore_bogus_error_responses" }, 410 { CTL_INT, NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR, "icmp_errors_use_inbound_ifaddr" }, 411 { CTL_INT, NET_IPV4_ICMP_RATELIMIT, "icmp_ratelimit" }, 412 { CTL_INT, NET_IPV4_ICMP_RATEMASK, "icmp_ratemask" }, 413 414 { CTL_INT, NET_IPV4_IPFRAG_HIGH_THRESH, "ipfrag_high_thresh" }, 415 { CTL_INT, NET_IPV4_IPFRAG_LOW_THRESH, "ipfrag_low_thresh" }, 416 { CTL_INT, NET_IPV4_IPFRAG_TIME, "ipfrag_time" }, 417 418 { CTL_INT, NET_IPV4_IPFRAG_SECRET_INTERVAL, "ipfrag_secret_interval" }, 419 /* NET_IPV4_IPFRAG_MAX_DIST "ipfrag_max_dist" no longer used */ 420 421 { CTL_INT, 2088 /* NET_IPQ_QMAX */, "ip_queue_maxlen" }, 422 423 /* NET_TCP_DEFAULT_WIN_SCALE unused */ 424 /* NET_TCP_BIC_BETA unused */ 425 /* NET_IPV4_TCP_MAX_KA_PROBES unused */ 426 /* NET_IPV4_IP_MASQ_DEBUG unused */ 427 /* NET_TCP_SYN_TAILDROP unused */ 428 /* NET_IPV4_ICMP_SOURCEQUENCH_RATE unused */ 429 /* NET_IPV4_ICMP_DESTUNREACH_RATE unused */ 430 /* NET_IPV4_ICMP_TIMEEXCEED_RATE unused */ 431 /* NET_IPV4_ICMP_PARAMPROB_RATE unused */ 432 /* NET_IPV4_ICMP_ECHOREPLY_RATE unused */ 433 /* NET_IPV4_ALWAYS_DEFRAG unused */ 434 {} 435 }; 436 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 24350 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-09-04 0:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-03 5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh 2019-09-03 7:41 ` Eric Dumazet 2019-09-03 15:39 ` Cyrus Sh 2019-09-03 15:59 ` Eric Dumazet 2019-09-03 16:06 ` Cyrus Sh 2019-09-03 16:17 ` Eric Dumazet 2019-09-03 16:27 ` Cyrus Sh 2019-09-03 16:42 ` Eric Dumazet 2019-09-03 22:45 ` David Miller 2019-09-04 0:45 ` Cyrus Sh 2019-09-03 22:43 ` David Miller 2019-09-03 16:12 ` Cyrus Sh 2019-09-03 16:16 ` Eric Dumazet 2019-09-03 7:45 ` kbuild test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).