netdev - RE: [PATCH iproute2] ss: better 32bit support

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: <063D6719AE5E284EB5DD2968C1650D6D1CB017F6@AcuExch.aculab.com>
Date:	Mon, 16 Mar 2015 16:39:35 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Ben Hutchings' <ben@...adent.org.uk>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	Stephen Hemminger <shemming@...cade.com>,
	netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH iproute2] ss: better 32bit support

From: Ben Hutchings
> On Tue, 2015-03-10 at 09:56 -0700, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@...gle.com>
> >
> > Socket cookies are 64bit, even if ss happens to be
> > a 32bit binary, running on a 64 bit host.
> >
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > ---
> >  misc/ss.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/misc/ss.c b/misc/ss.c
> > index 21a4366..ba58894 100644
> > --- a/misc/ss.c
> > +++ b/misc/ss.c
> > @@ -679,9 +679,9 @@ static inline char *sock_addr_get_str(const inet_prefix *prefix)
> >      return tmp;
> >  }
> >
> > -static unsigned long cookie_sk_get(uint32_t *cookie)
> > +static unsigned long long cookie_sk_get(const uint32_t *cookie)
> >  {
> > -	return (((unsigned long)cookie[1] << 31) << 1) | cookie[0];
> > +	return (((unsigned long long)cookie[1] << 31) << 1) | cookie[0];
> 
> Then you should also use << 32 instead of splitting it into two shifts.

I wondered if the code should be reading the value in the host's natural
endianness?
Then the code might be optimisable to:
	return *(unsigned long long *)cookie;
which rather begs the question as to why cookie is uint32_t[2] instead of
uint64_t.

	David