git: 7045b1603bdf - main - socket: Implement SO_RERROR

[Kevin Bowling]

On Wed, Jul 28, 2021 at 9:37 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
>
> On Wed, Jul 28, 2021 at 04:35:17PM +0000, Kevin Bowling wrote:
> > The branch main has been updated by kbowling (ports committer):
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=7045b1603bdf054145dd958a4acc17b410fb62a0
> >
> > commit 7045b1603bdf054145dd958a4acc17b410fb62a0
> > Author:     Roy Marples <roy at marples.name>
> > AuthorDate: 2021-07-28 15:46:59 +0000
> > Commit:     Kevin Bowling <kbowling at FreeBSD.org>
> > CommitDate: 2021-07-28 16:35:09 +0000
> >
> >     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
> > ---
> >  lib/libc/sys/getsockopt.2                          | 10 +++++++-
> >  sbin/route/route.c                                 | 13 +++++++++-
> >  sys/kern/uipc_sockbuf.c                            | 24 +++++++++++++++++
> >  sys/kern/uipc_socket.c                             | 30 ++++++++++++++++------
> >  sys/kern/uipc_usrreq.c                             |  2 +-
> >  sys/net/raw_usrreq.c                               | 11 ++++----
> >  .../bluetooth/socket/ng_btsocket_hci_raw.c         |  1 +
> >  sys/netgraph/ng_socket.c                           |  2 +-
> >  sys/netinet/ip_divert.c                            |  2 +-
> >  sys/netinet/ip_mroute.c                            |  2 +-
> >  sys/netinet/raw_ip.c                               |  3 +--
> >  sys/netinet/udp_usrreq.c                           |  2 +-
> >  sys/netinet6/icmp6.c                               |  6 ++---
> >  sys/netinet6/ip6_input.c                           |  1 +
> >  sys/netinet6/ip6_mroute.c                          |  3 ++-
> >  sys/netinet6/raw_ip6.c                             |  2 ++
> >  sys/netinet6/send.c                                |  2 +-
> >  sys/netinet6/udp6_usrreq.c                         |  2 +-
> >  sys/netipsec/keysock.c                             | 10 ++++----
> >  sys/sys/socket.h                                   |  1 +
> >  sys/sys/socketvar.h                                |  6 ++++-
> >  21 files changed, 100 insertions(+), 35 deletions(-)
>
> Hey Kevin,

Hi

> Would this commit be a good candidate for bumping __FreeBSD_version?

Off hand I don't think so but this is a weakly held opinion.

My reasoning is, this is just a new flag and doesn't affect the KBI or
ABI directly.  There are no MFC concerns I observe (other than
localized issues past stable-13, I haven't looked at 12 yet to see if
MFC is easy enough that I want to do it but I will to stable-13)

If we import something into src that uses this like ntpd, at most we'd
just enable the feature in its respective bmake or config.h or
wherever.  The ntpd bugzilla is down so I can't see how they
accomplished this particular feature test but I suspect it is just an
inline ifdef on SO_RERROR based on Roy's other patches.

On the ports side I think most external projects would use a feature
test macro of their respective build systems or ifdef on the SO_RERROR
definition in the minimal case (all of the API usages I know of do it
like that, see https://github.com/FRRouting/frr/pull/7242/files#diff-586e1a2c472fc93bf57ce9597b0ec6559e383bd161c959fd794d7316b23255dfR1429
for an example).

If you can demonstrate a reason to do it I will prep a phabricator and
seek review so I can commit it.

> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc