netdev - Re: [RFC] BPF program access to transport header

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: <20100430221047.GA19334@cel.leo>
Date:	Fri, 30 Apr 2010 23:10:47 +0100
From:	Paul LeoNerd Evans <leonerd@...nerd.org.uk>
To:	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [RFC] BPF program access to transport header

On Fri, Apr 30, 2010 at 10:15:09PM +0200, Patrick McHardy wrote:
> > I forsee a number of issues with trying to provide this:
> > 
> >  * How to provide the protocol number (e.g. 6 for TCP, 1 for ICMP) to
> >    the BPF program
> 
> Using one of the registers?

Using, how? What operation would put the numbers in there in the first
place?

I was thinking more of simply providing an ancilliary data area field,
similar to SKF_AD_PROTO and SKF_AD_HATYPE, following along the same
idea.

  LD WORD[SKF_AD_TRANSPROTO]

would then load the A register with the transport protocol number.

> >  * How to obtain the transport offset - AIUI, the skf_transport_offset()
> >    won't actually be set yet by the time the filter program runs.
> 
> For IPv4 its trivial. For IPv6 you could use ipv6_skip_exthdr().
> A slightly more flexible way would be to use something like the
> netfilter ipv6_find_hdr() function to get the offset of any header
> type. The protocol number could be returned in one of the registers
> (the other one would contain the offset).

I sortof meant in general. I really don't think trying to add
IPv4/IPv6-specific code into net/core/filter.c is going to go down well.

On the other hand, I observe from casual experimentation, that on
receipt of a TCP packet in IPv4 over ethernet, the offets are:

  mac=0 network=14 transport=14

This suggests more work needing to be done somewhere, because I'd expect
for an Ethernet/IPv4/TCP packet to get

  mac=0 network=14 transport=34

> >  * What to do if the underlying protocol doesn't support a transport
> >    layer above it - e.g. ARP.
> 
> I'd say simply abort the filter.

That sounds reasonable.

Another question occurs:

 * How to obtain the transport protocol number? I can easily provide it
   in the AD area; say as SKF_AD_TRANSPROTO; but how can
   net/core/filter.c know the value?

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