linux-kernel - Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

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

On Thu, Dec 16, 2021 at 06:29:40PM +0100, Ard Biesheuvel wrote:
> I think this series is a huge improvement, but it does not solve the
> UB problem completely. As we found, there are open issues in the GCC
> bugzilla regarding assumptions in the compiler that aligned quantities
> either overlap entirely or not at all. (e.g.,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363)

That isn't open, it was closed as INVALID back in May.

(Naturally) aligned quantities only overlap if they are the same datum.
This follows directly from the definition of (naturally) aligned.  There
is no mystery here.

All unaligned data need to be marked up properly.

> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in many places to
> conditionally emit code that violates C alignment rules.

Most of this is ABI, not C.  It is the ABI that requires certain
alignments.  Ignoring that plain does not work, but even if it would
you will end up with much slower generated code.

> whereas the following pattern makes more sense, I think, and does not
> violate any C rules in the common case:
> 
> #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>   // use unaligned accessors, which are cheap or even entirely free
> #else
>   // avoid unaligned accessors, as they are expensive; instead, reorganize
>   // the data so we don't need them (similar to setting NET_IP_ALIGN to 2)
> #endif

Yes, this looks more reasonable.

> 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.  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.

But this does not have much to do with alignment.


Segher