netdev - Re: [RFC/PATCH 0/3] UDP memory usage accounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 29 Sep 2007 13:55:15 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	satoshi.oshima.fk@...achi.com, johnpol@....mipt.ru,
	netdev@...r.kernel.org, haoki@...hat.com, yoshfuji@...ux-ipv6.org,
	yumiko.sugita.yf@...achi.com
Subject: Re: [RFC/PATCH 0/3] UDP memory usage accounting

On Fri, Sep 28, 2007 at 09:47:37PM -0700, David Miller wrote:
>
> There are two things we (might) need to guard against, one local and
> one remote.

Right I was focusing on the local threat.

> If you do a per-user limit, apache would basically just stop at that
> redzone point.  In some sense making the attack more effective because
> then it's trivial to shut down an entire web server this way.

Having a per-user limit doesn't necessarily mean that we have
to apply the limit differently to how we apply the system-wide
limits.  We could keep exactly the same code as we have now but
check against a per-user limit instead of a system-wide one.

In other words your apache scenario will continue to work as is
even with a per-user limit.

Now where it does become useful is when we have a rogue local
user.  As it is that user can chew up all of the budgeted TCP
memory by simply not calling recvmsg.  As I've stated in the
other email, the existing rlimits don't help because they're
per-process rather than per-user.

BTW, this is not fatal for TCP because TCP provides a minimum
amount of memory for each socket even when we are over the
limit.  However, if we this was implemented for UDP without
a minimum guarantee then it'd be quite useless.

> I see no valid argument against doing something similar for sockets.
> Such a register_shrinker() handler for TCP could, for example, look
> for TCP flows which haven't made forward progress in more than a
> certain amount of time and attempt to trim SKB memory from them.

Yes I agree this would be quite useful for sending.  However, it'll
be tough to shrink skbs that we've already acked for but the app
for some reason has decided to leave in the socket by not calling
recvmsg.

> UDP and other datagram sockets are troublesome because the memory
> gets wholly tied up immediately during the send call and it's not
> easy to liberate anything.  The nice part about datagram sockets,
> however, is that they make forward progress quickly and their
> memory is liberated as soon as the device transmits the packet.
> They don't have to wait for ACKs, windows openning up, or anything
> like that to happen.

Agreed.  Also the recvmsg case I've described above is much
simpler for UDP as we can just go through all the sockets and
free skbs at random :)

> To be honest I don't even think UDP is much of a real problem for this
> reason.

It's not a hard problem but we do need to have some code for it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html