netdev - Re: RFC: New BPF 'LOOP' instruction

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] [day] [month] [year] [list]

Message-ID: <20100803152757.GX11110@cel.leo>
Date:	Tue, 3 Aug 2010 16:27:58 +0100
From:	Paul LeoNerd Evans <leonerd@...nerd.org.uk>
To:	Rémi Denis-Courmont <remi@...lab.net>,
	netdev@...r.kernel.org
Subject: Re: RFC: New BPF 'LOOP' instruction

On Tue, Aug 03, 2010 at 06:17:40PM +0300, Rémi Denis-Courmont wrote:
> > And what happens when IPv8 comes along?
> > Or we want to parse IPX/SPX or
> > any of those thousands of other network protocols?
> 
> It does not work. That's why your SKB_TRANS_OFF proposal sucks totally because 
> it is not implementable. On the other hand, n IPv6-specific opcode sucks only 
> a little due to its ugliness and lack of forward compatibility.

Huh? So now you want to make every BPF program IPv6-specific, so we've
no hope in hell of making them cope with The Next Big Thing? As opposed
to my idea, which makes them neutral on the subject, and puts all the
knowledge of the protocol in the -kernel-, where we can easily implement
new things?

When some brandnew protocol comes long we'd like to filter on, kernel is
going to have to know about it. Which is -exactly- the same as the
current situation with regards SKF_NET_OFF / SKF_AD_PROTO, so I don't
really see what difference that makes.

-- 
Paul "LeoNerd" Evans

leonerd@...nerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)