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: <20100803133442.GQ11110@cel.leo>
Date:	Tue, 3 Aug 2010 14:34:43 +0100
From:	Paul LeoNerd Evans <leonerd@...nerd.org.uk>
To:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Cc:	andi@...stfloor.org
Subject: Re: RFC: New BPF 'LOOP' instruction

On Tue, Aug 03, 2010 at 06:07:54AM -0700, David Miller wrote:
> > How about simply adding a "skip ipv6 extension headers until header type
> > X" opcode?
> > 
> > I bet that would solve most of the problems here in practice.
> 
> BPF really should not have protocol specific opcodes.

You mean like the LD MSH instruction, the "load a byte, mask by 0x0f then
shift up two bits" one that's specific to fetching an IPv4 header length?

Lets look at this another way around then. Ignore my LOOP instruction
idea.

Already -right now- BPF has the SKF_NET_OFF + SFK_AD_PROTO information.
Lets consider an Ethernet/IP/TCP packet we've received:

[Ethernet header | IP header | TCP header ....]
^                ^
|                |
|                +-- SKF_NET_OFF is here
+-- 0 is here

SKF_AD_PROTO == 0x0800 (IPv4)


What if we added a new constant SKF_TRANS_OFF to store the start address
of the transport header, and a new SKF_AD storage area for the transport
protocol:

[Ethernet header | IP header | TCP header ....]
^                ^           ^
|                |           |
|                |           +--  SKF_TRANS_OFF is here
|                +-- SKF_NET_OFF is here
+-- 0 is here

SKF_AD_PROTO == 0x0800 (IPv4)
SKF_AD_TRANSPROTO == 6 (IPPROTO_TCP)


Now it's easy to see how IPv6 header processing fits into this. No
longer do we have to calculate the length of the IPv6 header, we can
just start off directly looking at the TCP header. I wanted TCP port 80;
no problem:

    LD BYTE[SKF_AD_PROTO]
    JEQ 0x0800, 1, #reject
    JEQ 0x86dd, 0, #reject
    LD BYTE[SKF_AD_TRANSPROTO]
    JEQ 6, 0, #reject
    LD BYTE[SKF_NET_OFF+0]
    JEQ 80, #accept, 0
    LD BYTE[SKF_NET_OFF+2]
    JEQ 80, 0, #reject
  accept:
    LD len
    RET A
  reject:
    RET 0

Hey presto; I've just accepted TCP src or dest port 80 on IPv4 or IPv6
without having any code to actually -parse- IPv4 or '6 headers.


Does this sound workable?

-- 
Paul "LeoNerd" Evans

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

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