xref: /freebsd/share/man/man9/pfil.9 (revision 2357939bc239bd5334a169b62313806178dd8f30)
1.\"	$NetBSD: pfil.9,v 1.22 2003/07/01 13:04:06 wiz Exp $
2.\"
3.\" Copyright (c) 1996 Matthew R. Green
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. The name of the author may not be used to endorse or promote products
15.\"    derived from this software without specific prior written permission.
16.\"
17.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
18.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
19.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
20.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
21.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
22.\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
23.\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
24.\" AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
25.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
26.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
27.\" SUCH DAMAGE.
28.\"
29.\" $FreeBSD$
30.Dd September 8, 2003
31.Dt PFIL 9
32.Os
33.Sh NAME
34.Nm pfil ,
35.Nm pfil_head_register ,
36.Nm pfil_head_unregister ,
37.Nm pfil_head_get ,
38.Nm pfil_hook_get ,
39.Nm pfil_add_hook ,
40.Nm pfil_remove_hook ,
41.Nm pfil_run_hooks
42.Nd packet filter interface
43.Sh SYNOPSIS
44.In sys/param.h
45.In sys/mbuf.h
46.In net/if.h
47.In net/pfil.h
48.Ft int
49.Fn pfil_head_register "struct pfil_head *head"
50.Ft int
51.Fn pfil_head_unregister "struct pfil_head *head"
52.Ft struct pfil_head *
53.Fn pfil_head_get "int af" "u_long dlt"
54.Ft struct packet_filter_hook *
55.Fn pfil_hook_get "int dir" "struct pfil_head *head"
56.Ft void
57.Fn pfil_add_hook "int (*func)()" "void *arg" "int flags" "struct pfil_head *"
58.Ft void
59.Fn pfil_remove_hook "int (*func)()" "void *arg" "int flags" "struct pfil_head *"
60.Ft int
61.Fn (*func) "void *arg" "struct mbuf **mp" "struct ifnet *" "int dir"
62.Ft int
63.Fn pfil_run_hooks "struct pfil_head *head" "struct mbuf **mp" "struct ifnet *" "int dir"
64.Sh DESCRIPTION
65The
66.Nm
67framework allows for a specified function to be invoked for every
68incoming or outgoing packet for a particular network I/O stream.
69These hooks may be used to implement a firewall or perform packet
70transformations.
71.Pp
72Packet filtering points are registered with
73.Fn pfil_head_register .
74Filtering points are identified by a key (void *) and a data link type
75(int) in the
76.Em pfil_head
77structure.
78Packet filters use the key and data link type to look up the filtering
79point with which they register themselves.
80The key is unique to the filtering point.
81The data link type is a
82.Xr bpf 4
83DLT constant indicating what kind of header is present on the packet
84at the filtering point.
85Filtering points may be unregistered with the
86.Fn pfil_head_unregister
87function.
88.Pp
89Packet filters register/unregister themselves with a filtering point
90with the
91.Fn pfil_add_hook
92and
93.Fn pfil_remove_hook
94functions, respectively.
95The head is looked up using the
96.Fn pfil_head_get
97function, which takes the key and data link type that the packet filter
98expects.
99Filters may provide an argument to be passed to the filter when
100invoked on a packet.
101.Pp
102When a filter is invoked, the packet appears just as if it
103.Dq came off the wire .
104That is, all protocol fields are in network byte order.
105The filter is called with its specified argument, the pointer to the
106pointer to the mbuf containing the packet, the pointer to the network
107interface that the packet is traversing, and the direction (PFIL_IN
108or PFIL_OUT) that the packet is traveling.
109The filter may change which mbuf the mbuf ** argument references.
110The filter returns an errno if the packet processing is to stop, or 0
111if the processing is to continue.
112If the packet processing is to stop, it is the responsibility of the
113filter to free the packet.
114.Pp
115The
116.Nm
117interface is enabled in the kernel via the
118.Sy PFIL_HOOKS
119option.
120.Sh RETURN VALUES
121If successful,
122.Fn pfil_head_get
123returns the pfil_head structure for the given key/dlt.
124.Fn pfil_add_hook
125and
126.Fn pfil_remove_hook
127return 0 if successful. If called with flag PFIL_WAITOK,
128.Fn pfil_remove_hook
129is expected to always succeed.
130.Pp
131.Fn pfil_head_unregister
132might sleep!
133.Sh HISTORY
134The
135.Nm
136interface first appeared in
137.Nx 1.3 .
138The
139.Nm
140input and output lists were originally implemented as
141.Fd \*[Lt]sys/queue.h\*[Gt]
142.Dv LIST
143structures;
144however this was changed in
145.Nx 1.4
146to
147.Dv TAILQ
148structures.
149This change was to allow the input and output filters to be processed in
150reverse order, to allow the same path to be taken, in or out of the kernel.
151.Pp
152The
153.Nm
154interface was changed in 1.4T to accept a 3rd parameter to both
155.Fn pfil_add_hook
156and
157.Fn pfil_remove_hook ,
158introducing the capability of per-protocol filtering.
159This was done primarily in order to support filtering of IPv6.
160.Pp
161In 1.5K, the
162.Nm
163framework was changed to work with an arbitrary number of filtering points,
164as well as be less IP-centric.
165.Pp
166Fine-grained locking was added in
167.Fx 5.2 .
168.Sh BUGS
169.Fn pfil_hook_get
170is only safe for internal use.
171.Pp
172FreeBSD implements only hooks for AF_INET and AF_INET6.
173Packets diverted through these hooks have data in
174host byte order contrary to the above statements.
175.Pp
176The
177.Xr bridge 4
178diverts inbound AF_INET traffic, but contrary to the above
179statements, the data is provided in host byte order.
180.Pp
181When a pfil_head is being modified no traffic is diverted
182(to avoid deadlock).
183This means that unwanted traffic may flow for a short period
184of time.
185.Sh SEE ALSO
186.Xr bpf 4 ,
187.Xr bridge 4
188