* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Thomas Graf @ 2005-06-12 14:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612133654.GA8951@alpha.home.local>
* Willy Tarreau <20050612133654.GA8951@alpha.home.local> 2005-06-12 15:36
> > The RST packet is sent by client A using its sequence numbers. Therefore
> > it will pass the sequence number check on server B.
> >
> > 4) server B resets the connection.
>
> No, precisely the RST sent by A will take its SEQ from C's ACK number.
> This is why B will *not* reset the connection (again, tested) if C's ACK
> was not within B's window.
Absolutely but it relies on the other stack being correctly implemented.
The attack would work perfectly fine if there wasn't the rule that a RST
must not be sent in response to another RST. The attack has been
successful and still is because some firewalls are configured to send
RSTs without respecting this rule.
I like your patch and the idea behind it, it can successfully defeat the
most simple method of preventing connections being established.
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 15:02 UTC (permalink / raw)
To: Thomas Graf; +Cc: Herbert Xu, davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612144426.GC22463@postel.suug.ch>
On Sun, Jun 12, 2005 at 04:44:26PM +0200, Thomas Graf wrote:
> * Willy Tarreau <20050612133654.GA8951@alpha.home.local> 2005-06-12 15:36
> > > The RST packet is sent by client A using its sequence numbers. Therefore
> > > it will pass the sequence number check on server B.
> > >
> > > 4) server B resets the connection.
> >
> > No, precisely the RST sent by A will take its SEQ from C's ACK number.
> > This is why B will *not* reset the connection (again, tested) if C's ACK
> > was not within B's window.
>
> Absolutely but it relies on the other stack being correctly implemented.
> The attack would work perfectly fine if there wasn't the rule that a RST
> must not be sent in response to another RST.
Of course, if you target a buggy stack, you can expect anything.
> The attack has been successful and still is because some firewalls
> are configured to send RSTs without respecting this rule.
In fact, I voluntarily did not speak about firewalls because almost all
of them are very sensible to TCP DoSes. First of all, all those which
don't check sequence numbers will blindly kill a session when they
receive an RST. And some of the other ones will not let certain ACK
packets pass through, which will make other DoS described in this
thread effective while it should not be, by not letting the server
tell the client to reset its session when really needed.
> I like your patch and the idea behind it, it can successfully defeat the
> most simple method of preventing connections being established.
That's what I thought, too. I have another one for 2.4.31 which only adds
a CONFIG option to remove the associated code, which reduces the image by
400 bytes.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Denis Vlasenko @ 2005-06-12 17:10 UTC (permalink / raw)
To: Willy Tarreau, David S. Miller; +Cc: xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050611074350.GD28759@alpha.home.local>
> Does it seem appropriate for mainline ? In this case, I would also backport
> it to 2.4 and send it to you for inclusion.
It does not contain a comment why it is configurable.
--
vda
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 17:36 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: David S. Miller, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <200506122010.33075.vda@ilport.com.ua>
On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > Does it seem appropriate for mainline ? In this case, I would also backport
> > it to 2.4 and send it to you for inclusion.
>
> It does not contain a comment why it is configurable.
You're right. Better with this ?
Willy
--
diff -pruNX dontdiff linux-2.6.11.11/Documentation/networking/ip-sysctl.txt linux-2.6.11.11-tcp/Documentation/networking/ip-sysctl.txt
--- linux-2.6.11.11/Documentation/networking/ip-sysctl.txt Sun Mar 6 13:08:46 2005
+++ linux-2.6.11.11-tcp/Documentation/networking/ip-sysctl.txt Sun Jun 12 19:28:50 2005
@@ -368,6 +368,27 @@ tcp_frto - BOOLEAN
where packet loss is typically due to random radio interference
rather than intermediate router congestion.
+tcp_simult_connect - BOOLEAN
+ Enables TCP simultaneous connect feature conforming to RFC793.
+ Strict implementation of RFC793 (TCP) requires support for a feature
+ called "simultaneous connect", which allows two clients to connect to
+ each other without anyone entering a listening state. While almost
+ never used, and supported by few OSes, Linux supports this feature.
+
+ However, it introduces a weakness in the protocol which makes it very
+ easy for an attacker to prevent a client from connecting to a known
+ server. The attacker only has to guess the source port to shut down
+ the client connection during its establishment. The impact is limited,
+ but it may be used to prevent an antivirus or IPS from fetching updates
+ and not detecting an attack, or to prevent an SSL gateway from fetching
+ a CRL for example.
+
+ If you want backwards compatibility with every possible application,
+ you should set it to 1. If you prefer to enhance security on your
+ systems at the risk of breaking very rare specific applications, you'd
+ better let it to 0.
+ Default: 0
+
somaxconn - INTEGER
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
diff -pruNX dontdiff linux-2.6.11.11/include/linux/sysctl.h linux-2.6.11.11-tcp/include/linux/sysctl.h
--- linux-2.6.11.11/include/linux/sysctl.h Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/include/linux/sysctl.h Sat Jun 11 09:00:22 2005
@@ -345,6 +345,7 @@ enum
NET_TCP_MODERATE_RCVBUF=106,
NET_TCP_TSO_WIN_DIVISOR=107,
NET_TCP_BIC_BETA=108,
+ NET_TCP_SIMULT_CONNECT=109,
};
enum {
diff -pruNX dontdiff linux-2.6.11.11/include/net/tcp.h linux-2.6.11.11-tcp/include/net/tcp.h
--- linux-2.6.11.11/include/net/tcp.h Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/include/net/tcp.h Sat Jun 11 08:56:16 2005
@@ -608,6 +608,7 @@ extern int sysctl_tcp_bic_low_window;
extern int sysctl_tcp_bic_beta;
extern int sysctl_tcp_moderate_rcvbuf;
extern int sysctl_tcp_tso_win_divisor;
+extern int sysctl_tcp_simult_connect;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff -pruNX dontdiff linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c
--- linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c Sat Jun 11 08:55:27 2005
@@ -690,6 +690,14 @@ ctl_table ipv4_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = NET_TCP_SIMULT_CONNECT,
+ .procname = "tcp_simult_connect",
+ .data = &sysctl_tcp_simult_connect,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff -pruNX dontdiff linux-2.6.11.11/net/ipv4/tcp_input.c linux-2.6.11.11-tcp/net/ipv4/tcp_input.c
--- linux-2.6.11.11/net/ipv4/tcp_input.c Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/net/ipv4/tcp_input.c Sun Jun 12 19:33:56 2005
@@ -84,6 +84,7 @@ int sysctl_tcp_adv_win_scale = 2;
int sysctl_tcp_stdurg;
int sysctl_tcp_rfc1337;
+int sysctl_tcp_simult_connect;
int sysctl_tcp_max_orphans = NR_FILE;
int sysctl_tcp_frto;
int sysctl_tcp_nometrics_save;
@@ -4620,10 +4621,12 @@ discard:
if (tp->rx_opt.ts_recent_stamp && tp->rx_opt.saw_tstamp && tcp_paws_check(&tp->rx_opt, 0))
goto discard_and_undo;
- if (th->syn) {
+ if (th->syn && sysctl_tcp_simult_connect) {
/* We see SYN without ACK. It is attempt of
* simultaneous connect with crossed SYNs.
* Particularly, it can be connect to self.
+ * This feature is disabled by default as it introduces a
+ * weakness in the protocol. It can be enabled by a sysctl.
*/
tcp_set_state(sk, TCP_SYN_RECV);
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Denis Vlasenko @ 2005-06-12 17:47 UTC (permalink / raw)
To: Willy Tarreau; +Cc: David S. Miller, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612173614.GA11157@alpha.home.local>
On Sunday 12 June 2005 20:36, Willy Tarreau wrote:
> On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > > Does it seem appropriate for mainline ? In this case, I would also backport
> > > it to 2.4 and send it to you for inclusion.
> >
> > It does not contain a comment why it is configurable.
>
> You're right. Better with this ?
Very nice. BTW, is there any real world applications which
ever used this?
> + If you want backwards compatibility with every possible application,
> + you should set it to 1. If you prefer to enhance security on your
> + systems at the risk of breaking very rare specific applications, you'd
> + better let it to 0.
> + Default: 0
This text leaves an impression that they exist.
--
vda
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 18:14 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: David S. Miller, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <200506122047.07257.vda@ilport.com.ua>
On Sun, Jun 12, 2005 at 08:47:07PM +0300, Denis Vlasenko wrote:
> On Sunday 12 June 2005 20:36, Willy Tarreau wrote:
> > On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > > > Does it seem appropriate for mainline ? In this case, I would also backport
> > > > it to 2.4 and send it to you for inclusion.
> > >
> > > It does not contain a comment why it is configurable.
> >
> > You're right. Better with this ?
>
> Very nice. BTW, is there any real world applications which
> ever used this?
Not that I'm aware of, but that does not mean they don't exist. Until
yesterday, I even thought that it was never implemented. As most other
systems don't implement it, the applications, if they exist, are Linux
or BSD-dependant. It's even difficult to use because the two ends must
loop around the connect() call until it succeeds, because as long as
they're not both trying to connect, they get RSTs back.
> > + If you want backwards compatibility with every possible application,
> > + you should set it to 1. If you prefer to enhance security on your
> > + systems at the risk of breaking very rare specific applications, you'd
> > + better let it to 0.
> > + Default: 0
>
> This text leaves an impression that they exist.
In doubt, I consider that they might exist. It's just like martians :-)
Willy
^ permalink raw reply
* Re: testing techniques to confirm the effectiveness of changes made to sch_gred.c
From: Rahul Hari @ 2005-06-12 20:05 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, netdev, lartc-request, diffserv-general
In-Reply-To: <20050612104628.GA22463@postel.suug.ch>
> > 1) Since the process deals with dequeueing, i have to make changes to
> > gred_dequeue only. If t->tab[0] != 0 then we dequeue the packet
> > otherwise do not dequeue it.
>
> What you describe above is: only dequeue when DP 0 is configured,
> probably not what you want. The only way to prioritize within gred
> the way you want is to modify dequeue() that it iterates through
> sch->q looking for a skb with tcindex==DP0 and use it instead of
> the skb at the queue head.
>
Thanks for the reply Thomas,
by checking t->tab[0]!=0, the approach I wanted to follow was that "if
I have a packet in the virtual queue with DP 0, then I should not be
dequeuing any packets from the other virtual queues", ie, take no
action at all.
with best regards,
Rahul
--
----------------------
"The fear you let build up in your mind is worse than the situation
that actually exists"
from "who moved my cheese"
---------------------------------------------------------------------------------
Rahul Hari
Senior Under Grad. Student,
Department of CSE,
ITBHU,
Varanasi.
Ph: +91-9845347020
rahul.hari@cse06.itbhu.org
------------------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH] net: fix sparse warning (plain int as NULL)
From: Jesper Juhl @ 2005-06-12 22:05 UTC (permalink / raw)
To: LKML; +Cc: David S. Miller, Ross Biro, netdev
Here's a patch to fix a small sparse warning in net/ipv4/tcp_input.c :
net/ipv4/tcp_input.c:4179:29: warning: Using plain integer as NULL pointer
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
---
net/ipv4/tcp_input.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.12-rc6-mm1-orig/net/ipv4/tcp_input.c 2005-06-12 15:58:58.000000000 +0200
+++ linux-2.6.12-rc6-mm1/net/ipv4/tcp_input.c 2005-06-12 23:58:41.000000000 +0200
@@ -4176,7 +4176,7 @@ int tcp_rcv_state_process(struct sock *s
*/
if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr &&
!tp->srtt)
- tcp_ack_saw_tstamp(tp, 0, 0);
+ tcp_ack_saw_tstamp(tp, NULL, 0);
if (tp->rx_opt.tstamp_ok)
tp->advmss -= TCPOLEN_TSTAMP_ALIGNED;
Please CC me on replies.
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Valdis.Kletnieks @ 2005-06-13 2:04 UTC (permalink / raw)
To: Willy Tarreau
Cc: Denis Vlasenko, David S. Miller, xschmi00, alastair, linux-kernel,
netdev
In-Reply-To: <20050612181425.GA11284@alpha.home.local>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Sun, 12 Jun 2005 20:14:25 +0200, Willy Tarreau said:
> On Sun, Jun 12, 2005 at 08:47:07PM +0300, Denis Vlasenko wrote:
> > Very nice. BTW, is there any real world applications which
> > ever used this?
>
> Not that I'm aware of, but that does not mean they don't exist. Until
> yesterday, I even thought that it was never implemented. As most other
> systems don't implement it, the applications, if they exist, are Linux
> or BSD-dependant.
A more likely explanation is that there existed TOPS-20 or Multics code
that actually used that for something. Remember that BSD and Linux both
came along long after RFC793 came out....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [patch 2.6.12-rc6] 3c59x: remove superfluous vortex_debug test from boomerang_start_xmit
From: Jeff Garzik @ 2005-06-13 3:31 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, akpm
In-Reply-To: <20050610142702.GC10449@tuxdriver.com>
John W. Linville wrote:
> Remove the superfluous test of "if (vortex_debug > 3)" inside the
> "if (vortex_debug > 6)" clause early in boomerang_start_xmit.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ACK (I presume akpm will send this one upstream)
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-13 4:48 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612142401.GA10772@alpha.home.local>
On Sun, Jun 12, 2005 at 04:24:01PM +0200, Willy Tarreau wrote:
>
> 1) no firewall in front of A
> - C spoofs A and sends a fake SYN to B
> - B responds to A with a SYN-ACK
> - A sends an RST to B, which clears the session
> - A wants to connect and sends its SYN to B which accepts it.
Well the attacker simply has to keep sending the same SYN packet
over and over again until A runs out of SYN retries.
What I really don't like about your patch is the fact that it is
trying to impose a policy decision (that of forbidding all
simultaneous connection initiations) inside the TCP stack.
A much better place to do that is netfilter. If you do it there
then not only will your protect all Linux machines from this attack,
but you'll also protect all the other BSD-derived TCP stacks.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-13 5:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050613044810.GA32103@gondor.apana.org.au>
On Mon, Jun 13, 2005 at 02:48:10PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 04:24:01PM +0200, Willy Tarreau wrote:
> >
> > 1) no firewall in front of A
> > - C spoofs A and sends a fake SYN to B
> > - B responds to A with a SYN-ACK
> > - A sends an RST to B, which clears the session
> > - A wants to connect and sends its SYN to B which accepts it.
>
> Well the attacker simply has to keep sending the same SYN packet
> over and over again until A runs out of SYN retries.
>
> What I really don't like about your patch is the fact that it is
> trying to impose a policy decision (that of forbidding all
> simultaneous connection initiations) inside the TCP stack.
It's the same for ECN or SYN cookies.
> A much better place to do that is netfilter. If you do it there
> then not only will your protect all Linux machines from this attack,
> but you'll also protect all the other BSD-derived TCP stacks.
Netfilter already blocks simultaneous connection. A SYN in return to
a SYN produces an INVALID state.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-13 6:17 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050613052404.GA7611@gondor.apana.org.au>
On Mon, Jun 13, 2005 at 03:24:04PM +1000, Herbert Xu wrote:
> On Mon, Jun 13, 2005 at 07:21:48AM +0200, Willy Tarreau wrote:
> >
> > > A much better place to do that is netfilter. If you do it there
> > > then not only will your protect all Linux machines from this attack,
> > > but you'll also protect all the other BSD-derived TCP stacks.
> >
> > Netfilter already blocks simultaneous connection. A SYN in return to
> > a SYN produces an INVALID state.
>
> Any reason why that isn't enough?
I don't think there are a lot of people who load ip_conntrack and insert
a single DROP rule on their servers just to workaround weaknesses in the
TCP stack. If they did, they would not be more confident into netfilter
either because it would be logical to expect the same reasoning (eg: let's
not fix XX here, TCP will catch it).
What's the problem with the sysctl ? If you prefer, I can change the patch
to keep the feature enabled by default so that only people aware of the
problem have to fix it by hand. But I found it better the other way : people
who need the feature enable it by hand.
Cheers,
willy
^ permalink raw reply
* [net-2.6.13 3/3] [IPSEC] Add XFRM_STATE_NOPMTUDISC flag
From: Herbert Xu @ 2005-06-13 7:39 UTC (permalink / raw)
To: David S. Miller, James Morris, Patrick McHardy, YOSHIFUJI Hideaki,
netdev
In-Reply-To: <20050613073353.GA21454@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Hi:
This patch adds the flag XFRM_STATE_NOPMTUDISC for xfrm states. It is
similar to the nopmtudisc on IPIP/GRE tunnels. It only has an effect
on IPv4 tunnel mode states. For these states, it will ensure that the
DF flag is always cleared.
This is primarily useful to work around ICMP blackholes.
In future this flag could also allow a larger MTU to be set within the
tunnel just like IPIP/GRE tunnels. This could be useful for short haul
tunnels where temporary fragmentation outside the tunnel is desired over
smaller fragments inside the tunnel.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: p3.patch --]
[-- Type: text/plain, Size: 3186 bytes --]
diff --git a/include/linux/pfkeyv2.h b/include/linux/pfkeyv2.h
--- a/include/linux/pfkeyv2.h
+++ b/include/linux/pfkeyv2.h
@@ -245,6 +245,7 @@ struct sadb_x_nat_t_port {
/* Security Association flags */
#define SADB_SAFLAGS_PFS 1
+#define SADB_SAFLAGS_NOPMTUDISC 0x20000000
#define SADB_SAFLAGS_DECAP_DSCP 0x40000000
#define SADB_SAFLAGS_NOECN 0x80000000
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -196,6 +196,7 @@ struct xfrm_usersa_info {
__u8 flags;
#define XFRM_STATE_NOECN 1
#define XFRM_STATE_DECAP_DSCP 2
+#define XFRM_STATE_NOPMTUDISC 4
};
struct xfrm_usersa_id {
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -33,6 +33,7 @@ static void xfrm4_encap(struct sk_buff *
struct dst_entry *dst = skb->dst;
struct xfrm_state *x = dst->xfrm;
struct iphdr *iph, *top_iph;
+ int flags;
iph = skb->nh.iph;
skb->h.ipiph = iph;
@@ -51,10 +52,13 @@ static void xfrm4_encap(struct sk_buff *
/* DS disclosed */
top_iph->tos = INET_ECN_encapsulate(iph->tos, iph->tos);
- if (x->props.flags & XFRM_STATE_NOECN)
+
+ flags = x->props.flags;
+ if (flags & XFRM_STATE_NOECN)
IP_ECN_clear(top_iph);
- top_iph->frag_off = iph->frag_off & htons(IP_DF);
+ top_iph->frag_off = (flags & XFRM_STATE_NOPMTUDISC) ?
+ 0 : (iph->frag_off & htons(IP_DF));
if (!top_iph->frag_off)
__ip_select_ident(top_iph, dst, 0);
diff --git a/net/ipv4/xfrm4_state.c b/net/ipv4/xfrm4_state.c
--- a/net/ipv4/xfrm4_state.c
+++ b/net/ipv4/xfrm4_state.c
@@ -7,12 +7,20 @@
*
*/
+#include <net/ip.h>
#include <net/xfrm.h>
#include <linux/pfkeyv2.h>
#include <linux/ipsec.h>
static struct xfrm_state_afinfo xfrm4_state_afinfo;
+static int xfrm4_init_flags(struct xfrm_state *x)
+{
+ if (ipv4_config.no_pmtu_disc)
+ x->props.flags |= XFRM_STATE_NOPMTUDISC;
+ return 0;
+}
+
static void
__xfrm4_init_tempsel(struct xfrm_state *x, struct flowi *fl,
struct xfrm_tmpl *tmpl,
@@ -109,6 +117,7 @@ __xfrm4_find_acq(u8 mode, u32 reqid, u8
static struct xfrm_state_afinfo xfrm4_state_afinfo = {
.family = AF_INET,
.lock = RW_LOCK_UNLOCKED,
+ .init_flags = xfrm4_init_flags,
.init_tempsel = __xfrm4_init_tempsel,
.state_lookup = __xfrm4_state_lookup,
.find_acq = __xfrm4_find_acq,
diff --git a/net/key/af_key.c b/net/key/af_key.c
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -690,6 +690,8 @@ static struct sk_buff * pfkey_xfrm_state
sa->sadb_sa_flags |= SADB_SAFLAGS_NOECN;
if (x->props.flags & XFRM_STATE_DECAP_DSCP)
sa->sadb_sa_flags |= SADB_SAFLAGS_DECAP_DSCP;
+ if (x->props.flags & XFRM_STATE_NOPMTUDISC)
+ sa->sadb_sa_flags |= SADB_SAFLAGS_NOPMTUDISC;
/* hard time */
if (hsc & 2) {
@@ -974,6 +976,8 @@ static struct xfrm_state * pfkey_msg2xfr
x->props.flags |= XFRM_STATE_NOECN;
if (sa->sadb_sa_flags & SADB_SAFLAGS_DECAP_DSCP)
x->props.flags |= XFRM_STATE_DECAP_DSCP;
+ if (sa->sadb_sa_flags & SADB_SAFLAGS_NOPMTUDISC)
+ x->props.flags |= XFRM_STATE_NOPMTUDISC;
lifetime = (struct sadb_lifetime*) ext_hdrs[SADB_EXT_LIFETIME_HARD-1];
if (lifetime != NULL) {
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-13 7:45 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050613061748.GA13144@alpha.home.local>
On Mon, Jun 13, 2005 at 08:17:48AM +0200, Willy Tarreau wrote:
>
> What's the problem with the sysctl ? If you prefer, I can change the patch
> to keep the feature enabled by default so that only people aware of the
> problem have to fix it by hand. But I found it better the other way : people
> who need the feature enable it by hand.
Well that's exactly my problem :)
I reckon it should be off by default because the threat posed by
this problem is IMHO small compared to some of the other standard
threats that are applicable to TCP. Plus this is a well-documented
feature so we can't be sure that someone somewhere isn't depending
on it.
However, if it were off by default then there is very little value
in providing it at all since the same thing can be achived easily
through netfilter.
Anyway, let's leave it to Dave to make the decision.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Jan Rychter @ 2005-06-13 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <1118435188.6423.26.camel@mindpipe>
>>>>> "Lee" == Lee Revell <rlrevell@joe-job.com> writes:
Lee> On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
>> >
>> > Adding kernel level wireless autoconfiguration duplicates the
>> > effort. Since I am not going to give up a requirement to be able
>> > to stay radio silent at boot (me too wants freedom, not only you),
>> > you need to add disable=1 module parameter to each driver, which
>> > adds to the mess.
>> >
>> > ALSA does the Right Thing. Sound is completely muted out at module
>> > load. It's a user freedom to set desired volume level after that.
>>
>> Yeah right. I remember I had to google for 10 minutes to find the
>> answer for this one. Why would you install something, for it to not
>> work?
>>
>> It thing of Mute in ALSA is stupid. If you want Sound, you install
>> the Sound and enable it. Why would it make you google for more
>> things to do? ALSA mute on install is WAY way, not OK.
Lee> It took you 10 minutes of googling before you thought to try the
Lee> mixer? Sorry dude, this is PEBKAC.
Oh, really, you think this works so well? Ever tried to use more than
one soundcard? A USB audio device? Ever wondered why oh why one has to
always check and twiddle with the mixers? Why (it seems) setting the
volume of USB audio devices via alsamixer doesn't work for apps which
use OSS emulation? Ever wondered why alsactl restore doesn't get called
by udev by default?
The current Linux approach (most distributions) is to let the user be
the master. Which means lots of typing, configuring, tweaking. Try that
on a tablet pc without a keyboard.
Things should Just Work. I wish most Linux developers tried using a Mac
at least once in their lifetimes.
--J.
^ permalink raw reply
* Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?
From: David S. Miller @ 2005-06-13 21:24 UTC (permalink / raw)
To: ak; +Cc: gnuwind, casavan, linux-kernel, netdev
In-Reply-To: <m11x79dwcb.fsf@muc.de>
From: Andi Kleen <ak@muc.de>
Date: Sat, 11 Jun 2005 12:25:08 +0200
> Yes, there were some changes here when it was converted to a common
> function for all hash tables (alloc_large_system_hash - the function
> with the argument list from hell). Anyways, here's a quick fix.
>
> DaveM for your consideration.
>
> Adjust TCP mem order check to new alloc_large_system_hash
>
> Signed-off-by: Andi Kleen <ak@suse.de>
I just reread those NUMA changes, and they changed the heuristics
for sizing things at the same time as moving over to the
alloc_large_system_hash() change.
The change was to move from (21 - PAGE_SHIFT) and (23 - PAGE_SHIFT)
to (25 - PAGE_SHIFT) and (27 - PAGE_SHIFT) respectively.
This is the part of the NUMA TCP changes that made the sysctl setting
behavior differ.
Andi's patch is the least intrusive fix for 2.6.12, so I will
apply it. But longer term these heuristics need to be revisited
as a whole.
^ permalink raw reply
* Re: [PATCH] net: fix sparse warning (plain int as NULL)
From: David S. Miller @ 2005-06-13 21:31 UTC (permalink / raw)
To: jesper.juhl; +Cc: juhl-lkml, linux-kernel, ross.biro, netdev
In-Reply-To: <9a8748490506131421707008ed@mail.gmail.com>
From: Jesper Juhl <jesper.juhl@gmail.com>
Date: Mon, 13 Jun 2005 23:21:56 +0200
> Since tcp_ack_saw_tstamp() in 2.6.12-rc6-git6 only takes two arguments
> this patch is only relevant for -mm.
Thanks for the clarification.
^ permalink raw reply
* Re: udp.c
From: Herbert Xu @ 2005-06-13 21:42 UTC (permalink / raw)
To: David S. Miller; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <20050613.124515.104034144.davem@davemloft.net>
David S. Miller <davem@davemloft.net> wrote:
> From: Jesper Juhl <jesper.juhl@gmail.com>
> Date: Mon, 13 Jun 2005 19:23:36 +0200
>
>> Why not remove the function and audit the code for users (and if any,
>> remove them)...? Let's get rid of it instead of having a function sit
>> around the only purpose of which is to BUG();
>
> Then if someone breaks that invariant, we'll never find out.
>
> The code is staying, sorry.
It'll dump the stack anyway if we just make it a NULL pointer.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -201,11 +201,6 @@ fail:
return 1;
}
-static void udp_v4_hash(struct sock *sk)
-{
- BUG();
-}
-
static void udp_v4_unhash(struct sock *sk)
{
write_lock_bh(&udp_hash_lock);
@@ -1370,7 +1365,7 @@ struct proto udp_prot = {
.recvmsg = udp_recvmsg,
.sendpage = udp_sendpage,
.backlog_rcv = udp_queue_rcv_skb,
- .hash = udp_v4_hash,
+ /* .hash is intentionally left NULL */
.unhash = udp_v4_unhash,
.get_port = udp_v4_get_port,
.obj_size = sizeof(struct udp_sock),
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -135,11 +135,6 @@ fail:
return 1;
}
-static void udp_v6_hash(struct sock *sk)
-{
- BUG();
-}
-
static void udp_v6_unhash(struct sock *sk)
{
write_lock_bh(&udp_hash_lock);
@@ -1048,7 +1043,7 @@ struct proto udpv6_prot = {
.sendmsg = udpv6_sendmsg,
.recvmsg = udpv6_recvmsg,
.backlog_rcv = udpv6_queue_rcv_skb,
- .hash = udp_v6_hash,
+ /* .hash is intentionally left NULL */
.unhash = udp_v6_unhash,
.get_port = udp_v6_get_port,
.obj_size = sizeof(struct udp6_sock),
^ permalink raw reply
* Re: udp.c
From: David S. Miller @ 2005-06-13 21:57 UTC (permalink / raw)
To: herbert; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <E1Dhwho-0001mn-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 14 Jun 2005 07:42:52 +1000
> It'll dump the stack anyway if we just make it a NULL pointer.
Some platforms don't handle that very cleanly, for example
it may be necessary to have something mapped at page zero
for one reason or another.
^ permalink raw reply
* Re: udp.c
From: Herbert Xu @ 2005-06-13 23:04 UTC (permalink / raw)
To: David S. Miller; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <20050613.145716.88477054.davem@davemloft.net>
On Mon, Jun 13, 2005 at 02:57:16PM -0700, David S. Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 14 Jun 2005 07:42:52 +1000
>
> > It'll dump the stack anyway if we just make it a NULL pointer.
>
> Some platforms don't handle that very cleanly, for example
> it may be necessary to have something mapped at page zero
> for one reason or another.
Are there any existing platforms that do that in kernel mode?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: udp.c
From: David S. Miller @ 2005-06-13 23:20 UTC (permalink / raw)
To: herbert; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <20050613230422.GA7269@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 14 Jun 2005 09:04:22 +1000
> On Mon, Jun 13, 2005 at 02:57:16PM -0700, David S. Miller wrote:
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Tue, 14 Jun 2005 07:42:52 +1000
> >
> > > It'll dump the stack anyway if we just make it a NULL pointer.
> >
> > Some platforms don't handle that very cleanly, for example
> > it may be necessary to have something mapped at page zero
> > for one reason or another.
>
> Are there any existing platforms that do that in kernel mode?
X86 did, especially during bootup, for a long time.
I know the highly optimized sparc64 instruction TLB miss handler
doesn't handle this properly and this usually hangs the machine.
I've put some checks in there that tries to handle it properly,
but there are still some cases that pass through.
^ permalink raw reply
* Re: udp.c
From: Andi Kleen @ 2005-06-13 23:53 UTC (permalink / raw)
To: David S. Miller; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <20050613.162052.41635836.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 14 Jun 2005 09:04:22 +1000
>
>> On Mon, Jun 13, 2005 at 02:57:16PM -0700, David S. Miller wrote:
>> > From: Herbert Xu <herbert@gondor.apana.org.au>
>> > Date: Tue, 14 Jun 2005 07:42:52 +1000
>> >
>> > > It'll dump the stack anyway if we just make it a NULL pointer.
>> >
>> > Some platforms don't handle that very cleanly, for example
>> > it may be necessary to have something mapped at page zero
>> > for one reason or another.
>>
>> Are there any existing platforms that do that in kernel mode?
>
> X86 did, especially during bootup, for a long time.
Still does, as does x86-64, but actually it could be changed now using
change_page_attr (and then later undoing it). Is it worth it?
-Andi
^ permalink raw reply
* Re: udp.c
From: David S. Miller @ 2005-06-14 0:00 UTC (permalink / raw)
To: ak; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <m1fyvlbyp7.fsf@muc.de>
From: Andi Kleen <ak@muc.de>
Date: Tue, 14 Jun 2005 01:53:56 +0200
> Still does, as does x86-64, but actually it could be changed now using
> change_page_attr (and then later undoing it). Is it worth it?
A lot of bootup OOPS's have occured in the past and
were never discovered until someone on a non-x86
platform tested the patch.
^ permalink raw reply
* Re: udp.c
From: Andi Kleen @ 2005-06-14 0:12 UTC (permalink / raw)
To: David S. Miller; +Cc: jesper.juhl, mru, rommer, bernd, linux-kernel, netdev
In-Reply-To: <20050613.170045.74749212.davem@davemloft.net>
On Mon, Jun 13, 2005 at 05:00:45PM -0700, David S. Miller wrote:
> From: Andi Kleen <ak@muc.de>
> Date: Tue, 14 Jun 2005 01:53:56 +0200
>
> > Still does, as does x86-64, but actually it could be changed now using
> > change_page_attr (and then later undoing it). Is it worth it?
>
> A lot of bootup OOPS's have occured in the past and
> were never discovered until someone on a non-x86
> platform tested the patch.
Ok I can fix it, but only reasonably after mem_init (at least without
hacking up change_page_attr a lot to deal with bootmem).
Is that still worth it?
-Andi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox