BSD Commit Log Search

ipfw: migrate ipfw to 32-bit size rule numbers

This changes ABI due to the changed opcodes and includes the
following:
 * rule numbers and named object indexes converted to 32-bits
 * all hardcoded maximum rule number was replaced with
   IPFW_DEFAULT_RULE macro
 * now it is possible to grow maximum numbers or rules in
   build time
 * several opcodes converted to ipfw_insn_u32 to keep rulenum:
   O_CALL, O_SKIPTO
 * call stack modified to keep u32 rulenum. The behaviour of
   O_CALL opcode was changed to avoid possible packets looping.
   Now when call stack is overflowed or mbuf tag allocation
   failed, a packet will be dropped instead of skipping to next
   rule.
 * 'return' action now have two modes to specify return point:
   'next-rulenum' and 'next-rule'
 * new lookup key added for O_IP_DST_LOOKUP opcode 'lookup rulenum'

    [21 lines not shown]

socket: Add an option to retrieve a socket's FIB number

The SO_SETFIB option can be used to set a socket's FIB number, but there
is no way to retrieve it.  Rename SO_SETFIB to SO_FIB and implement a
handler for it for getsockopt(2).

Reviewed by:    glebius
MFC after:      2 weeks
Sponsored by:   Klara, Inc.
Sponsored by:   Stormshield
Differential Revision:  https://reviews.freebsd.org/D48834

(cherry picked from commit ee951eb59f2136a604e3fbb12abf8d8344da0c99)

socket: Add an option to retrieve a socket's FIB number

The SO_SETFIB option can be used to set a socket's FIB number, but there
is no way to retrieve it.  Rename SO_SETFIB to SO_FIB and implement a
handler for it for getsockopt(2).

Reviewed by:    glebius
MFC after:      2 weeks
Sponsored by:   Klara, Inc.
Sponsored by:   Stormshield
Differential Revision:  https://reviews.freebsd.org/D48834

socket: Move SO_SPLICE next to other socket option constants

Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D47626

(cherry picked from commit 48a88a4ee95a725a435a817401ea4c0d9c990cd1)

socket: Move SO_SPLICE next to other socket option constants

Reviewed by:    markj
Differential Revision:  https://reviews.freebsd.org/D47626

socket: Implement SO_SPLICE

This is a feature which allows one to splice two TCP sockets together
such that data which arrives on one socket is automatically pushed into
the send buffer of the spliced socket.  This can be used to make TCP
proxying more efficient as it eliminates the need to copy data into and
out of userspace.

The interface is copied from OpenBSD, and this implementation aims to be
compatible.  Splicing is enabled by setting the SO_SPLICE socket option.
When spliced, data that arrives on the receive buffer is automatically
forwarded to the other socket.  In particular, splicing is a
unidirectional operation; to splice a socket pair in both directions,
SO_SPLICE needs to be applied to both sockets.  More concretely, when
setting the option one passes the following struct:

    struct splice {
            int fd;
            off_t max;

    [41 lines not shown]

socket: Implement SO_SPLICE

This is a feature which allows one to splice two TCP sockets together
such that data which arrives on one socket is automatically pushed into
the send buffer of the spliced socket.  This can be used to make TCP
proxying more efficient as it eliminates the need to copy data into and
out of userspace.

The interface is copied from OpenBSD, and this implementation aims to be
compatible.  Splicing is enabled by setting the SO_SPLICE socket option.
When spliced, data that arrives on the receive buffer is automatically
forwarded to the other socket.  In particular, splicing is a
unidirectional operation; to splice a socket pair in both directions,
SO_SPLICE needs to be applied to both sockets.  More concretely, when
setting the option one passes the following struct:

    struct splice {
            int fd;
            off_t max;

    [39 lines not shown]

include: ssp: fortify <sys/socket.h>

The entire recv*() implementation set is ripe for opportunities to
validate, so do what we can with what we have.

Reviewed by:    markj
Sponsored by:   Klara, Inc.
Sponsored by:   Stormshield
Differential Revision:  https://reviews.freebsd.org/D45686

sockets: define shutdown(2) constants in cpp namespace

There is software that uses SHUT_RD, SHUT_WR as preprocessor defines and
its build was broken by enum declaration.  Keep the enum, but provide
defines to propagate the constants to cpp namespace.

PR:             277994
PR:             277995
Fixes:          c3276e02beab825824e3147b31af33af66298430

sockets: remove unused KPIs to manipulate sockets

These KPIs were added in dd0e6c383a9f0 and through 15 years had zero use.
They slightly remind what IfAPI does for struct ifnet.  But IfAPI does
that for the sake of large collection of NIC drivers not being aware of
struct ifnet.  For the sockets it is unclear what could be a large
collection of externally written kernel modules that need extensively use
sockets and not be aware of their internals at the same time. This
isolation of a structure knowledge requires a lot of work, and just
throwing in a few KPIs isn't helpful.

Reviewed by:            kib, olce, markj
Differential Revision:  https://reviews.freebsd.org/D44311

sockets: make pr_shutdown fully protocol specific method

Disassemble a one-for-all soshutdown() into protocol specific methods.
This creates a small amount of copy & paste, but makes code a lot more
self documented, as protocol specific method would execute only the code
that is relevant to that protocol and nothing else.  This also fixes a
couple recent regressions and reduces risk of future regressions.  The
extended KPI for the new pr_shutdown removes need for the extra pr_flush
which was added for the sake of SCTP which could not perform its shutdown
properly with the old one.  Particularly for SCTP this change streamlines
a lot of code.

Some notes on why certain parts of code were copied or were not to certain
protocols:
* The (SS_ISCONNECTED | SS_ISCONNECTING | SS_ISDISCONNECTING) check is
  needed only for those protocols that may be connected or disconnected.
* The above reduces into only SS_ISCONNECTED for those protocols that
  always connect instantly.
* The ENOTCONN and continue processing hack is left only for datagram

    [16 lines not shown]

sockets: make shutdown(2) how argument a enum

Reviwed by:             tuexen
Differential Revision:  https://reviews.freebsd.org/D43412

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by:           Netflix

sys: Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/

Similar commit in current:
(cherry picked from commit 2ff63af9b88c)

sys: Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/

netlink: add AF_NETLINK / PF_NETLINK definitions

Reviewed by:    glebius
Differential Revision: https://reviews.freebsd.org/D36174
MFC after:      1 weeks

(cherry picked from commit a4b8c6d9d50ec03f490587854ec82c9790193f46)

inpcb: garbage collect so_sototcpcb()

It had very little use and required inpcb layer to know tcpcb.

divert: declare PF_DIVERT domain and stop abusing PF_INET

The divert(4) is not a protocol of IPv4.  It is a socket to
intercept packets from ipfw(4) to userland and re-inject them
back.  It can divert and re-inject IPv4 and IPv6 packets today,
but potentially it is not limited to these two protocols.  The
IPPROTO_DIVERT does not belong to known IP protocols, it
doesn't even fit into u_char.  I guess, the implementation of
divert(4) was done the way it is done basically because it was
easier to do it this way, back when protocols for sockets were
intertwined with IP protocols and domains were statically
compiled in.

Moving divert(4) out of inetsw accomplished two important things:

1) IPDIVERT is getting much closer to be not dependent on INET.
   This will be finalized in following changes.
2) Now divert socket no longer aliases with raw IPv4 socket.
   Domain/proto selection code won't need a hack for SOCK_RAW and

    [5 lines not shown]

netlink: add AF_NETLINK / PF_NETLINK definitions

Reviewed by:    glebius
Differential Revision: https://reviews.freebsd.org/D36174
MFC after:      1 weeks

uipc_socket.c: Modify MSG_TLSAPPDATA to only do Alert Records

Without this patch, the MSG_TLSAPPDATA flag would cause
soreceive_generic() to return ENXIO for any non-application
data record in a TLS receive stream.

This works ok for TLS1.2, since Alert records appear to be
the only non-application data records received.
However, for TLS1.3, there can be post-handshake handshake
records, such as NewSessionKey sent to the client from the
server. These handshake records cannot be handled by the
upcall which does an SSL_read() with length == 0.

It appears that the client can simply throw away these
NewSessionKey records, but to do so, it needs to receive
them within the kernel.

This patch modifies the semantics of MSG_TLSAPPDATA slightly,
so that it only applies to Alert records and not Handshake

    [3 lines not shown]

uipc_socket.c: Modify MSG_TLSAPPDATA to only do Alert Records

Without this patch, the MSG_TLSAPPDATA flag would cause
soreceive_generic() to return ENXIO for any non-application
data record in a TLS receive stream.

This works ok for TLS1.2, since Alert records appear to be
the only non-application data records received.
However, for TLS1.3, there can be post-handshake handshake
records, such as NewSessionKey sent to the client from the
server. These handshake records cannot be handled by the
upcall which does an SSL_read() with length == 0.

It appears that the client can simply throw away these
NewSessionKey records, but to do so, it needs to receive
them within the kernel.

This patch modifies the semantics of MSG_TLSAPPDATA slightly,
so that it only applies to Alert records and not Handshake

    [5 lines not shown]

socket: Implement SO_RERROR

SO_RERROR indicates that receive buffer overflows should be handled as
errors. Historically receive buffer overflows have been ignored and
programs could not tell if they missed messages or messages had been
truncated because of overflows. Since programs historically do not
expect to get receive overflow errors, this behavior is not the
default.

This is really really important for programs that use route(4) to keep
in sync with the system. If we loose a message then we need to reload
the full system state, otherwise the behaviour from that point is
undefined and can lead to chasing bogus bug reports.

Reviewed by:    philip (network), kbowling (transport), gbe (manpages)
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D26652

(cherry picked from commit 7045b1603bdf054145dd958a4acc17b410fb62a0)

socket: Implement SO_RERROR

SO_RERROR indicates that receive buffer overflows should be handled as
errors. Historically receive buffer overflows have been ignored and
programs could not tell if they missed messages or messages had been
truncated because of overflows. Since programs historically do not
expect to get receive overflow errors, this behavior is not the
default.

This is really really important for programs that use route(4) to keep
in sync with the system. If we loose a message then we need to reload
the full system state, otherwise the behaviour from that point is
undefined and can lead to chasing bogus bug reports.

Reviewed by:    philip (network), kbowling (transport), gbe (manpages)
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D26652

(cherry picked from commit 7045b1603bdf054145dd958a4acc17b410fb62a0)

socket: Implement SO_RERROR

SO_RERROR indicates that receive buffer overflows should be handled as
errors. Historically receive buffer overflows have been ignored and
programs could not tell if they missed messages or messages had been
truncated because of overflows. Since programs historically do not
expect to get receive overflow errors, this behavior is not the
default.

This is really really important for programs that use route(4) to keep
in sync with the system. If we loose a message then we need to reload
the full system state, otherwise the behaviour from that point is
undefined and can lead to chasing bogus bug reports.

Reviewed by:    philip (network), kbowling (transport), gbe (manpages)
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D26652

Revert "SO_RERROR indicates that receive buffer overflows should be handled as errors."
Wrong version of the change was pushed inadvertenly.

This reverts commit 4a01b854ca5c2e5124958363b3326708b913af71.

SO_RERROR indicates that receive buffer overflows should be handled as errors.
Historically receive buffer overflows have been ignored and programs
could not tell if they missed messages or messages had been truncated
because of overflows. Since programs historically do not expect to get
receive overflow errors, this behavior is not the default.

This is really really important for programs that use route(4) to keep in sync
with the system. If we loose a message then we need to reload the full system
state, otherwise the behaviour from that point is undefined and can lead
to chasing bogus bug reports.

unix(4): Enhance LOCAL_CREDS_PERSISTENT ABI

As this ABI is still fresh (r367287), let's correct some mistakes now:

- Version the structure to allow for future changes
- Include sender's pid in control message structure
- Use a distinct control message type from the cmsgcred / sockcred mess

Discussed with: kib, markj, trasz
Differential Revision:  https://reviews.freebsd.org/D27084

Introduce scalable route multipath.

This change is based on the nexthop objects landed in D24232.

The change introduces the concept of nexthop groups.
Each group contains the collection of nexthops with their
 relative weights and a dataplane-optimized structure to enable
 efficient nexthop selection.

Simular to the nexthops, nexthop groups are immutable. Dataplane part
 gets compiled during group creation and is basically an array of
 nexthop pointers, compiled w.r.t their weights.

With this change, `rt_nhop` field of `struct rtentry` contains either
 nexthop or nexthop group. They are distinguished by the presense of
 NHF_MULTIPATH flag.
All dataplane lookup functions returns pointer to the nexthop object,
leaving nexhop groups details inside routing subsystem.


    [37 lines not shown]

sys: clean up empty lines in .c and .h files

MFH

Sponsored by:   Rubicon Communications, LLC (netgate.com)