linux-kernel - Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing

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:   Tue, 05 Feb 2019 18:52:18 -0800
From:   Joe Perches <joe@...ches.com>
To:     Paul Zimmerman <pauldzim@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        David Miller <davem@...emloft.net>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing

On Tue, 2019-02-05 at 19:27 -0700, Paul Zimmerman wrote:
> On Tue, 2019-02-05, Joe Perches wrote:
> > On Tue, 2019-02-05 at 12:04 -0800, Eric Dumazet wrote:
> > > On 02/05/2019 10:42 AM, Joe Perches wrote:
> > > > It's declared after a pointer so it is already is 2 byte aligned.
> > > > 
> > > > A lot of drivers wouldn't work otherwise.
> > > 
> > > Maybe these drivers are only used on arches where this does not matter.
> > 
> > Possible.
> > 
> > I had only grepped through the sources looking for
> > declarations using:
> > 
> > $ git grep -B1 '\[ETH_ALEN\];' -- '*.c' | grep -A1 '\*'
> > 
> > It's quite a few files in net/ too btw.
> > 
> > I still think adding __align(<even#>) is unnecessary here unless
> > it follows something like a bool or a u8.
> 
> Um, guys, this is practically C-101.
> 
> From C99, 6.7.2.1:
> 
> > 13/ Within a structure object, the non-bit-field members and the units in
> > which bit-fields reside have addresses that increase in the order in which
> > they are declared. A pointer to a structure object, suitably converted,
> > points to its initial member (or if that member is a bit-field, then to the
> > unit in which it resides), and vice versa. There may be unnamed padding
> > within a structure object, but not at its beginning.
> 
> AFAIK there is no such language in the spec regarding variable layout on
> the stack. So Joe, you are totally off-base here.

We're not talking about the spec, see the void * arithmetic
bit, we're talking about what gcc and clang actually do.

This spec regarding variable layout structure members could
also apply to any of the unpacked protocol headers like in
include/uapi/linux/ip.h (struct iphdr for instance)

So, it's not me that's off here.
I do understand the c90 spec pretty well.

Eric's comment about stack layout randomization certainly applies.

Perhaps it's reasonable to add some __aligned(<even#>) to the
appropriate [ETH_ALEN] declarations.