On Tue, Jun 04, 2019 at 08:25:31AM -0700, Matthias Kaehlcke wrote:
From: Rasmus Villemoes linux@rasmusvillemoes.dk
commit ef4d6f6b275c498f8e5626c99dbeefdc5027f843 upstream
The ror32 implementation (word >> shift) | (word << (32 - shift) has undefined behaviour if shift is outside the [1, 31] range. Similarly for the 64 bit variants. Most callers pass a compile-time constant (naturally in that range), but there's an UBSAN report that these may actually be called with a shift count of 0.
Instead of special-casing that, we can make them DTRT for all values of shift while also avoiding UB. For some reason, this was already partly done for rol32 (which was well-defined for [0, 31]). gcc 8 recognizes these patterns as rotates, so for example
__u32 rol32(__u32 word, unsigned int shift) { return (word << (shift & 31)) | (word >> ((-shift) & 31)); }
compiles to
0000000000000020 <rol32>: 20: 89 f8 mov %edi,%eax 22: 89 f1 mov %esi,%ecx 24: d3 c0 rol %cl,%eax 26: c3 retq
Older compilers unfortunately do not do as well, but this only affects the small minority of users that don't pass constants.
Due to integer promotions, ro[lr]8 were already well-defined for shifts in [0, 8], and ro[lr]16 were mostly well-defined for shifts in [0, 16] (only mostly - u16 gets promoted to _signed_ int, so if bit 15 is set, word << 16 is undefined). For consistency, update those as well.
Link: http://lkml.kernel.org/r/20190410211906.2190-1-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk Reported-by: Ido Schimmel idosch@mellanox.com Tested-by: Ido Schimmel idosch@mellanox.com Reviewed-by: Will Deacon will.deacon@arm.com Cc: Vadim Pasternak vadimp@mellanox.com Cc: Andrey Ryabinin aryabinin@virtuozzo.com Cc: Jacek Anaszewski jacek.anaszewski@gmail.com Cc: Pavel Machek pavel@ucw.cz Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Matthias Kaehlcke mka@chromium.org
Hi Greg and Sasha,
Please pick this patch for 5.1. It fixes (at least) crashes due to undefined instructions in BPF code on arm32 when building with clang:
I see that Greg has queued it up yesterday, it should be in the next release. Thanks!
-- Thanks, Sasha