Date:   Fri, 17 Dec 2021 07:35:18 -0600
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rich Felker <dalias@...c.org>,
        "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
        "Richard Russon (FlatCap)" <ldm@...tcap.org>,
        X86 ML <x86@...nel.org>,
        Amitkumar Karwar <amitkarwar@...il.com>,
        James Morris <jmorris@...ei.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paul Mackerras <paulus@...ba.org>,
        linux-m68k <linux-m68k@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "open list:SPARC + UltraSPARC (sparc/sparc64)" 
        <sparclinux@...r.kernel.org>, Stafford Horne <shorne@...il.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Yoshinori Sato <ysato@...rs.osdn.me>,
        Russell King <linux@...linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Kalle Valo <kvalo@...eaurora.org>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Jakub Kicinski <kuba@...nel.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Jonas Bonn <jonas@...thpole.se>,
        Kees Cook <keescook@...omium.org>,
        Arnd Bergmann <arnd@...db.de>,
        Ganapathi Bhat <ganapathi017@...il.com>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "openrisc@...ts.librecores.org" <openrisc@...ts.librecores.org>,
        Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Jens Axboe <axboe@...nel.dk>, Arnd Bergmann <arnd@...nel.org>,
        John Johansen <john.johansen@...onical.com>,
        Xinming Hu <huxinming820@...il.com>,
        Vineet Gupta <vgupta@...opsys.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-ntfs-dev@...ts.sourceforge.net" 
        <linux-ntfs-dev@...ts.sourceforge.net>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
        <netdev@...r.kernel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" 
        <linuxppc-dev@...ts.ozlabs.org>,
        Sharvari Harisangam <sharvari.harisangam@....com>
Subject: Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

On Fri, Dec 17, 2021 at 12:34:53PM +0000, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 16 December 2021 18:56
> ...
> > > The only remaining problem here is reinterpreting a char* pointer to a
> > > u32*, e.g., for accessing the IP address in an Ethernet frame when
> > > NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
> > > as I understand it.
> > 
> > The problem is never casting a pointer to pointer to character type, and
> > then later back to an appriopriate pointer type.
> > These things are both required to work.
> 
> I think that is true of 'void *', not 'char *'.

No, see 6.3.2.3/7.  Both are allowed (and behave the same in fact).

> 'char' is special in that 'strict aliasing' doesn't apply to it.
> (Which is actually a pain sometimes.)

That has nothing to do with it.  Yes, you can validly access any memory
as a character type, but that has nothing to do with what pointer casts
are allowed and which are not.

> > The problem always is accessing something as if it
> > was something of another type, which is not valid C.  This however is
> > exactly what -fno-strict-aliasing allows, so that works as well.
> 
> IIRC the C language only allows you to have pointers to valid data items.
> (Since they can only be generated by the & operator on a valid item.)

Not so.  For example you are explicitly allowed to have pointers one
past the last element of an array (and do arithmetic on that!), and of
course null pointers are a thing.

C allows you to make up pointers from integers as well.  This is
perfectly fine to do.  Accessing anything via such pointers might well
be not standard C, of course.

> Indirecting any other pointer is probably UB!

If a pointer points to an object, indirecting it gives an lvalue of that
object.  It does not matter how you got that pointer, all that matters
is that it points at a valid object.

> This (sort of) allows the compiler to 'look through' casts to find
> what the actual type is (or might be).
> It can then use that information to make optimisation choices.
> This has caused grief with memcpy() calls that are trying to copy
> a structure that the coder knows is misaligned to an aligned buffer.

This is 6.5/7.

Alignment is 6.2.8 but it doesn't actually come into play at all here.

> So while *(unaligned_ptr *)char_ptr probably has to work.

Only if the original pointer points to an object that is correct
(including correctly aligned) for such an lvalue.

> If the compiler can see *(unaligned_ptr *)(char *)int_ptr it can
> assume the alignment of the 'int_ptr' and do a single aligned access.

It is undefined behaviour to have an address in int_ptr that is not
correctly aligned for whatever type it points to.


Segher

Powered by blists - more mailing lists