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:   Fri, 17 Dec 2021 12:34:53 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Segher Boessenkool' <segher@...nel.crashing.org>,
        Ard Biesheuvel <ardb@...nel.org>
CC:     "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

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 *'.
'char' is special in that 'strict aliasing' doesn't apply to it.
(Which is actually a pain sometimes.)

> 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.)
Indirecting any other pointer is probably UB!

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.

So while *(unaligned_ptr *)char_ptr probably has to work.
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.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ