[Top] [All Lists]

Re: skb->security and friends

To: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: skb->security and friends
From: Andi Kleen <ak@xxxxxxx>
Date: Sat, 27 Oct 2001 13:34:37 +0200
Cc: Andi Kleen <ak@xxxxxxx>, design@xxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200110270423.f9R4N3m09808@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>; from mcr@xxxxxxxxxxxxxxxxxxxxxx on Sat, Oct 27, 2001 at 12:23:02AM -0400
References: <20011026214235.A5375@xxxxxxxxxxxxx> <200110270423.f9R4N3m09808@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.3.16i
On Sat, Oct 27, 2001 at 12:23:02AM -0400, Michael Richardson wrote:
> 1) We wish to set something in netfilter and/or advanced routing and examine
>    it in dev xmit.        (for entering the tunnel)
> 2) We wish to set something in dev recv, and examine it in netfilter.
>       (for checking that the packet that exited the tunnel complied to policy)

netfilter is not a layer in this definition, so ->cb is not free for your
use. It would be e.g. if you're a device driver and manage the skb in queue
or if you're TCP/IP and also manage it in your queues.

>     Andi> I would recommend to use nfmark. as far as I can see you'll need
>     Andi> destination cache support anyways, and it gets you that for free.
>   Thanks.  We'll use nfmark.
>   What will you guys use? We'll need between 16 and 32 bits of nfmark :-)

For the current kernel nfmark is just an opaque value with no policy.

ipchains/tables currently expose 32bit to the administrators for firewall
purposes; if you don't want to wrestle with the admins about these bits
it may be needed to expand it to 64bit and reserve the upper 32bits for
kernel uses.


<Prev in Thread] Current Thread [Next in Thread>