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

On Thu, Dec 16, 2021 at 9:29 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in many places to
> conditionally emit code that violates C alignment rules. E.g., there
> is this example in Documentation/core-api/unaligned-memory-access.rst:
>
> bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
> {
> #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>   u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
>              ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
>   return fold == 0;
> #else

It probably works fine in practice - the one case we had was really
pretty special, and about the vectorizer doing odd things.

But I think we should strive to convert these to use
"get_unaligned()", since code generation is fine. It still often makes
sense to have that test for the config variable, simply because the
approach might be different if we know unaligned accesses are slow.

So I'll happily take patches that do obvious conversions to
get_unaligned() where they make sense, but I don't think we should
consider this some huge hard requirement.

                 Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ