linux-kernel - Re: [GIT pull] x86/urgent for v5.15-rc3

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Sep 2021 10:21:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT pull] x86/urgent for v5.15-rc3

On Sun, Sep 26, 2021 at 3:30 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
>  - Prevent undefined behaviour to the potential unaligned accesss in the
>    instroction decoder library.

What a horrible fix that is.

This is why we have "get_unaligned()". It might use memcpy()
internally on some architectures (it doesn't really any more - Arnd
cleaned it all up and now it uses a pointer that is marked unaligned),
but more importantly it explains _why_ something is done the way it's
done, rather than be an odd memcpy().

Oh well. The memcpy works, and compilers will do the right thing for
it, but it's ugly.

In this case, it's actually *doubly* ugly, though, because we
literally have functions to "load unaligned data in little-endian
format".

So instead of doing a "memcpy()", followed by a magic special macro
that does a "switch (sizeof(t))" and does a "le*_to_cpu()" on the
result, the code could  literally have used the functions that do this
all for them.

Ugh. Pulled. But it's ugly.

           Linus