netdev - [0/3] tun: Add packet 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-next>] [day] [month] [year] [list]

Message-ID: <20090204104825.GA21257@gondor.apana.org.au>
Date:	Wed, 4 Feb 2009 21:48:25 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: [0/3] tun: Add packet accounting

Hi Dave:

Remember that UDP packet loss issue with virtulisation that one of
the Japanese guys menteioned at Plumbers'? Well it's back.

My initial reaction was obviously to suggest a different protocol,
however, that didn't get very far because we do such a great job
at handling it on baremetal.  That has created an unhealthy
dependency on the part of the users :)

Since no one has been brave enough to suggest removing the truesize
accounting for UDP, I've bitten the bullet and implemented the
same thing for the tuntap device.  This essentially brings UDP
in virtualisation to a par with UDP on baremetal as far as pushback
by the physical NIC is concerned.

On the plus side, we can spin this as a security feature :) It
stops the tun users from potentially pinning down unlimited amounts
of kernel memory (the entity creating the tun device is not
necessarily the one pushing traffic through it).

And I've got to say that it's not as ugly as I feared initially,
with just two lines changed in the core code.  The performance
impact should also be small, as only one conditional is added
on the fast path.

Of course the solution is not perfect in that it only handles
bridging right now.  But as bridging represents 99% of our current
virtualisation user base, it should be good enough.  Making this
work for routing isn't all that hard but requires more surgery
in the protocol (IP) stacks.

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