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

Message-ID: <20100803141924.GV11110@cel.leo>
Date:	Tue, 3 Aug 2010 15:19:24 +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 04:16:02PM +0200, Rémi Denis-Courmont wrote:
> > Is there any way it could be done lazily, at the moment that filter.c
> > knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
> 
> You would essentially need to implement dedicated parsing for each
> protocols family.
> So you might as well add an opcode dedicated to IPv6...

And what happens when IPv8 comes along? Or we want to parse IPX/SPX or
any of those thousands of other network protocols?

I'd prefer to keep the BPF layer (relatively) protocol-neutral. Yes, we
have LDX MSH which with hindsight I'd say looks like a very
protocol-specific instruction. But there's nothing protocol-specific
about asking for where the transport header is and what type it is, no
moreso than asking where the network offset and type are, out of the
link-level header. This just extends that layer model.

How to -implement- it is quite another matter.

-- 
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)