linux-kernel - RE: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to gre

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]

Date:   Wed, 16 Mar 2022 10:12:00 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jakub Kicinski' <kuba@...nel.org>,
        David Ahern <dsahern@...nel.org>
CC:     "menglong8.dong@...il.com" <menglong8.dong@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "mingo@...hat.com" <mingo@...hat.com>, "xeb@...l.ru" <xeb@...l.ru>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "imagedong@...cent.com" <imagedong@...cent.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kafai@...com" <kafai@...com>,
        "talalahmad@...gle.com" <talalahmad@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "alobakin@...me" <alobakin@...me>,
        "flyingpeng@...cent.com" <flyingpeng@...cent.com>,
        "mengensun@...cent.com" <mengensun@...cent.com>,
        "dongli.zhang@...cle.com" <dongli.zhang@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Biao Jiang <benbjiang@...cent.com>
Subject: RE: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to
 gre_rcv()

From: Jakub Kicinski
> Sent: 16 March 2022 04:56
> 
> On Tue, 15 Mar 2022 21:49:01 -0600 David Ahern wrote:
> > >>  	ver = skb->data[1]&0x7f;
> > >> -	if (ver >= GREPROTO_MAX)
> > >> +	if (ver >= GREPROTO_MAX) {
> > >> +		reason = SKB_DROP_REASON_GRE_VERSION;
> > >
> > > TBH I'm still not sure what level of granularity we should be shooting
> > > for with the reasons. I'd throw all unexpected header values into one
> > > bucket, not go for a reason per field, per protocol. But as I'm said
> > > I'm not sure myself, so we can keep what you have..
> >
> > I have stated before I do not believe every single drop point in the
> > kernel needs a unique reason code. This is overkill. The reason augments
> > information we already have -- the IP from kfree_skb tracepoint.
> 
> That's certainly true. I wonder if there is a systematic way of
> approaching these additions that'd help us picking the points were
> we add reasons less of a judgment call.

Is it worth considering splitting the 'reason' into two parts?
Eg x << 16 | y
One part being the overall reason - and probably a define.
The other qualifying the actual failing test and probably just
being a number.

Then you get an overall view of the fails (which might even
be counted) while still being able to locate the actual
failing test.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)