netdev - Re: [net-next v2] net: change accept_ra_min_rtr

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: <ZMJmziEZy+9baINH@corigine.com>
Date: Thu, 27 Jul 2023 14:45:02 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Maciej Żenczykowski <maze@...gle.com>
Cc: Patrick Rohr <prohr@...gle.com>,
	"David S . Miller" <davem@...emloft.net>,
	Linux Network Development Mailing List <netdev@...r.kernel.org>,
	Lorenzo Colitti <lorenzo@...gle.com>,
	David Ahern <dsahern@...nel.org>
Subject: Re: [net-next v2] net: change accept_ra_min_rtr_lft to affect all RA
 lifetimes

On Thu, Jul 27, 2023 at 02:38:24PM +0200, Maciej Żenczykowski wrote:
> On Thu, Jul 27, 2023 at 2:24 PM Simon Horman <simon.horman@...igine.com> wrote:
> >
> > On Wed, Jul 26, 2023 at 04:07:01PM -0700, Patrick Rohr wrote:
> > > accept_ra_min_rtr_lft only considered the lifetime of the default route
> > > and discarded entire RAs accordingly.
> > >
> > > This change renames accept_ra_min_rtr_lft to accept_ra_min_lft, and
> > > applies the value to individual RA sections; in particular, router
> > > lifetime, PIO preferred lifetime, and RIO lifetime. If any of those
> > > lifetimes are lower than the configured value, the specific RA section
> > > is ignored.
> > >
> > > In order for the sysctl to be useful to Android, it should really apply
> > > to all lifetimes in the RA, since that is what determines the minimum
> > > frequency at which RAs must be processed by the kernel. Android uses
> > > hardware offloads to drop RAs for a fraction of the minimum of all
> > > lifetimes present in the RA (some networks have very frequent RAs (5s)
> > > with high lifetimes (2h)). Despite this, we have encountered networks
> > > that set the router lifetime to 30s which results in very frequent CPU
> > > wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the
> > > WiFi firmware) entirely on such networks, it seems better to ignore the
> > > misconfigured routers while still processing RAs from other IPv6 routers
> > > on the same network (i.e. to support IoT applications).
> > >
> > > The previous implementation dropped the entire RA based on router
> > > lifetime. This turned out to be hard to expand to the other lifetimes
> > > present in the RA in a consistent manner; dropping the entire RA based
> > > on RIO/PIO lifetimes would essentially require parsing the whole thing
> > > twice.
> > >
> > > Fixes: 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
> > > Cc: Maciej Żenczykowski <maze@...gle.com>
> > > Cc: Lorenzo Colitti <lorenzo@...gle.com>
> > > Cc: David Ahern <dsahern@...nel.org>
> > > Signed-off-by: Patrick Rohr <prohr@...gle.com>
> > > ---
> > >  Documentation/networking/ip-sysctl.rst |  8 ++++----
> > >  include/linux/ipv6.h                   |  2 +-
> > >  include/uapi/linux/ipv6.h              |  2 +-
> > >  net/ipv6/addrconf.c                    | 14 ++++++++-----
> > >  net/ipv6/ndisc.c                       | 27 +++++++++++---------------
> > >  5 files changed, 26 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
> > > index 37603ad6126b..a66054d0763a 100644
> > > --- a/Documentation/networking/ip-sysctl.rst
> > > +++ b/Documentation/networking/ip-sysctl.rst
> > > @@ -2288,11 +2288,11 @@ accept_ra_min_hop_limit - INTEGER
> > >
> > >       Default: 1
> > >
> > > -accept_ra_min_rtr_lft - INTEGER
> > > -     Minimum acceptable router lifetime in Router Advertisement.
> > > +accept_ra_min_lft - INTEGER
> > > +     Minimum acceptable lifetime value in Router Advertisement.
> >
> > Hi Patrick, all,
> >
> > I am concerned about UAPI-breakage aspects of changing the name of a sysctl.
> > Can we discuss that?
> 
> This isn't uapi yet as it (the old name) was only merged a few days ago.

Ack, then I have no UAPI concern.