netdev - Re: [PATCH v3 net-next] l2tp: Refactor the codes with existing macros instead of literal number

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: <20160822094813.bpch2uzyhtbnrqmx@alphalink.fr>
Date:   Mon, 22 Aug 2016 11:48:13 +0200
From:   Guillaume Nault <g.nault@...halink.fr>
To:     Philp Prindeville <philipp@...fish-solutions.com>
Cc:     fgao@...vckh6395k16k5.yundunddos.com, paulus@...ba.org,
        davem@...emloft.net, netdev@...r.kernel.org, gfree.wind@...il.com
Subject: Re: [PATCH v3 net-next] l2tp: Refactor the codes with existing
 macros instead of literal number

On Sun, Aug 21, 2016 at 04:36:52PM -0600, Philp Prindeville wrote:
> Inline
> 
> 
> On 08/20/2016 09:52 AM, fgao@...vckh6395k16k5.yundunddos.com wrote:
> > From: Gao Feng <fgao@...ai8.com>
> > 
> > Use PPP_ALLSTATIONS, PPP_UI, and SEND_SHUTDOWN instead of 0xff,
> > 0x03, and 2 separately.
> > 
> > Signed-off-by: Gao Feng <fgao@...ai8.com>
> > ---
> >   v3: Modify the subject;
> >   v2: Only replace the literal number with macros according to Guillaume's advice
> >   v1: Inital patch
> > 
> >   net/l2tp/l2tp_ppp.c | 8 ++++----
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
> > index d9560aa..65e2fd6 100644
> > --- a/net/l2tp/l2tp_ppp.c
> > +++ b/net/l2tp/l2tp_ppp.c
> > @@ -177,7 +177,7 @@ static int pppol2tp_recv_payload_hook(struct sk_buff *skb)
> >   	if (!pskb_may_pull(skb, 2))
> >   		return 1;
> > -	if ((skb->data[0] == 0xff) && (skb->data[1] == 0x03))
> > +	if ((skb->data[0] == PPP_ALLSTATIONS) && (skb->data[1] == PPP_UI))
> 
> This should have used PPP_ADDRESS() and PPP_CONTROL() here.
>
Then please justify how would that make the code more readable.
We're not trying to interpret a known valid PPP header here.

> >   		skb_pull(skb, 2);
> 
> This magic number should go away.
>
Again, this is *not* a magic number. We've explicitely accessed the
first _two_ header bytes and want to skip them.
pskb_may_pull(2), ->data[0], ->data[1] and skb_pull(2) all go together.

There's even a nice comment telling you what is done and why:
	/* Skip PPP header, if present.	 In testing, Microsoft L2TP clients
	 * don't send the PPP header (PPP header compression enabled), but
	 * other clients can include the header. So we cope with both cases
	 * here. The PPP header is always FF03 when using L2TP.
	 *
	 * Note that skb->data[] isn't dereferenced from a u16 ptr here since
	 * the field may be unaligned.
	 */
Apart from the unprecise "PPP header" term, which should be read as
"address and control fields", things should be quite clear.

> > @@ -282,7 +282,7 @@ static void pppol2tp_session_sock_put(struct l2tp_session *session)
> >   static int pppol2tp_sendmsg(struct socket *sock, struct msghdr *m,
> >   			    size_t total_len)
> >   {
> > -	static const unsigned char ppph[2] = { 0xff, 0x03 };
> > +	static const unsigned char ppph[2] = {PPP_ALLSTATIONS, PPP_UI};
> 
> PPP has a 4-byte header.  Where's the protocol value?
>
No, PPP header (whatever you include in it) is of variable length. And
the protocol has already been set by the PPP layer anyway.
We're in L2TP here.