linux-kernel - Re: [PATCH v3 2/6] lib/base64: Optimize base64

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]

Message-ID: <20251027141802.61dbfbb2@pumpkin>
Date: Mon, 27 Oct 2025 14:18:02 +0000
From: David Laight <david.laight.linux@...il.com>
To: Guan-Chun Wu <409411716@....tku.edu.tw>
Cc: Caleb Sander Mateos <csander@...estorage.com>,
 akpm@...ux-foundation.org, axboe@...nel.dk, ceph-devel@...r.kernel.org,
 ebiggers@...nel.org, hch@....de, home7438072@...il.com, idryomov@...il.com,
 jaegeuk@...nel.org, kbusch@...nel.org, linux-fscrypt@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
 sagi@...mberg.me, tytso@....edu, visitorckw@...il.com, xiubli@...hat.com
Subject: Re: [PATCH v3 2/6] lib/base64: Optimize base64_decode() with
 reverse lookup tables

On Mon, 27 Oct 2025 21:12:00 +0800
Guan-Chun Wu <409411716@....tku.edu.tw> wrote:

...
> Hi David,
> 
> I noticed your suggested approach:
> val_24 = t[b[0]] | t[b[1]] << 6 | t[b[2]] << 12 | t[b[3]] << 18;
> Per the C11 draft, this can lead to undefined behavior.
> "If E1 has a signed type and nonnegative value, and E1 × 2^E2 is
> representable in the result type, then that is the resulting value;
> otherwise, the behavior is undefined."
> Therefore, left-shifting a negative signed value is undefined behavior.

Don't worry about that, there are all sorts of places in the kernel
where shifts of negative values are technically undefined.

They are undefined because you get different values for 1's compliment
and 'sign overpunch' signed integers.
Even for 2's compliment C doesn't require a 'sign bit replicating'
right shift.
(And I suspect both gcc and clang only support 2's compliment.)

I don't think even clang is stupid enough to silently not emit any
instructions for shifts of negative values.
It is another place where it should be 'implementation defined' rather
than 'undefined' behaviour.

> Perhaps we could change the code as shown below. What do you think?

If you are really worried, change the '<< n' to '* (1 << n)' which
obfuscates the code.
The compiler will convert it straight back to a simple shift.

I bet that if you look hard enough even 'a | b' is undefined if
either is negative.

	David

	David