The warning is caused by call to rorXX(), if the second parameters of
this function "shift" is zero. In such case UBSAN reports the warning
for the next expression: (word << (XX - shift), where XX is
64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
Fix adds validation of this parameter - in case it's equal zero, no
need to rotate, just original "word" is to be returned to caller.
The UBSAN undefined behavior warning has been reported for call to
ror32():
[ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
[ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
[ 11.441647] Hardware name: Mellanox Technologies Ltd. MSN3800/VMOD0007, BIOS 5.11 01/06/2019
[ 11.441650] Call Trace:
[ 11.441661] dump_stack+0x71/0xab
[ 11.441668] ubsan_epilogue+0x9/0x49
[ 11.441676] __ubsan_handle_shift_out_of_bounds+0x1ea/0x241
[ 11.441683] ? __ubsan_handle_load_invalid_value+0x137/0x137
[ 11.441691] ? __module_text_address+0x11/0x90
[ 11.441697] ? widen_string+0x27/0x140
[ 11.441704] ? regmap_readable+0x76/0xc0
[ 11.441709] ? regmap_readable+0x76/0xc0
[ 11.441718] ? mlxplat_mlxcpld_readable_reg+0x1f/0x30 [mlx_platform]
[ 11.441723] ? regmap_volatile+0x40/0xb0
[ 11.441729] ? mlxplat_mlxcpld_volatile_reg+0x1f/0x30 [mlx_platform]
[ 11.441735] ? _regmap_read+0x11c/0x210
[ 11.441741] ? __mutex_lock_slowpath+0x10/0x10
[ 11.441750] ? mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[ 11.441756] mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[ 11.441764] ? mlxreg_led_brightness_get+0x270/0x270 [leds_mlxreg]
[ 11.441769] ? del_timer+0xe0/0xe0
[ 11.441776] ? bust_spinlocks+0x90/0x90
[ 11.441784] led_blink_setup+0x47/0x1d0
[ 11.441792] timer_trig_activate+0x8f/0x175 [ledtrig_timer]
[ 11.441799] ? kvasprintf_const+0xb0/0xb0
[ 11.441805] ? led_delay_on_show+0x50/0x50 [ledtrig_timer]
[ 11.441810] ? _raw_write_lock_bh+0xe0/0xe0
[ 11.441815] ? _raw_read_lock_irqsave+0x80/0x80
[ 11.441822] led_trigger_set+0x2cf/0x4d0
[ 11.441829] ? led_trigger_show+0x1f0/0x1f0
[ 11.441834] ? __mutex_lock_slowpath+0x10/0x10
[ 11.441840] ? kernfs_get_active+0xb2/0x120
[ 11.441845] ? kernfs_get_parent+0x50/0x50
[ 11.441851] led_trigger_store+0xe7/0x130
[ 11.441858] kernfs_fop_write+0x19a/0x250
[ 11.441863] ? sysfs_kf_bin_read+0x120/0x120
[ 11.441869] vfs_write+0xf5/0x230
[ 11.441875] ksys_write+0xa1/0x120
[ 11.441881] ? __ia32_sys_read+0x50/0x50
[ 11.441888] ? __do_page_fault+0x3e4/0x640
[ 11.441895] do_syscall_64+0x73/0x160
[ 11.441900] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 11.441905] RIP: 0033:0x7f955749f730
[ 11.441911] Code: 73 01 c3 48 8b 0d 68 d7 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d d9 2f 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 9b 01 00 48 89 04 24
[ 11.441914] RSP: 002b:00007ffd4da04488 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 11.441920] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f955749f730
[ 11.441923] RDX: 0000000000000006 RSI: 0000000001a14408 RDI: 0000000000000001
[ 11.441926] RBP: 0000000001a14408 R08: 00007f955775f760 R09: 00007f9557da9b40
[ 11.441929] R10: 0000000000000097 R11: 0000000000000246 R12: 0000000000000006
[ 11.441932] R13: 0000000000000001 R14: 00007f955775e600 R15: 0000000000000006
Reported-by: Ido Schimmel <[email protected]>
Signed-off-by: Vadim Pasternak <[email protected]>
---
include/linux/bitops.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 602af23b98c7..02c00f3c8205 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
*/
static inline __u64 ror64(__u64 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (64 - shift));
}
@@ -90,6 +93,9 @@ static inline __u32 rol32(__u32 word, unsigned int shift)
*/
static inline __u32 ror32(__u32 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (32 - shift));
}
@@ -110,6 +116,9 @@ static inline __u16 rol16(__u16 word, unsigned int shift)
*/
static inline __u16 ror16(__u16 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (16 - shift));
}
@@ -130,6 +139,9 @@ static inline __u8 rol8(__u8 word, unsigned int shift)
*/
static inline __u8 ror8(__u8 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (8 - shift));
}
--
2.11.0
On Sun, 7 Apr 2019 12:53:25 +0000 Vadim Pasternak <[email protected]> wrote:
> The warning is caused by call to rorXX(), if the second parameters of
> this function "shift" is zero. In such case UBSAN reports the warning
> for the next expression: (word << (XX - shift), where XX is
> 64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
> Fix adds validation of this parameter - in case it's equal zero, no
> need to rotate, just original "word" is to be returned to caller.
>
> The UBSAN undefined behavior warning has been reported for call to
> ror32():
> [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
hm, do we care?
> ...
>
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
> */
> static inline __u64 ror64(__u64 word, unsigned int shift)
> {
> + if (!shift)
> + return word;
> +
> return (word >> shift) | (word << (64 - shift));
> }
Is there any known architecture or compiler for which UL<<64 doesn't
reliably produce zero? Is there any prospect that this will become a
problem in the future?
(resend, cc Andrey)
On Sun, 7 Apr 2019 12:53:25 +0000 Vadim Pasternak <[email protected]> wrote:
> The warning is caused by call to rorXX(), if the second parameters of
> this function "shift" is zero. In such case UBSAN reports the warning
> for the next expression: (word << (XX - shift), where XX is
> 64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
> Fix adds validation of this parameter - in case it's equal zero, no
> need to rotate, just original "word" is to be returned to caller.
>
> The UBSAN undefined behavior warning has been reported for call to
> ror32():
> [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
hm, do we care?
> ...
>
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
> */
> static inline __u64 ror64(__u64 word, unsigned int shift)
> {
> + if (!shift)
> + return word;
> +
> return (word >> shift) | (word << (64 - shift));
> }
Is there any known architecture or compiler for which UL<<64 doesn't
reliably produce zero? Is there any prospect that this will become a
problem in the future?
> -----Original Message-----
> From: Andrew Morton <[email protected]>
> Sent: Tuesday, April 09, 2019 1:52 AM
> To: Vadim Pasternak <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; Ido Schimmel <[email protected]>; Andrey
> Ryabinin <[email protected]>
> Subject: Re: [PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning
> for rotation right
>
> (resend, cc Andrey)
>
> On Sun, 7 Apr 2019 12:53:25 +0000 Vadim Pasternak <[email protected]>
> wrote:
>
> > The warning is caused by call to rorXX(), if the second parameters of
> > this function "shift" is zero. In such case UBSAN reports the warning
> > for the next expression: (word << (XX - shift), where XX is 64, 32,
> > 16, 8 for respectively ror64, ror32, ror16, ror8.
> > Fix adds validation of this parameter - in case it's equal zero, no
> > need to rotate, just original "word" is to be returned to caller.
> >
> > The UBSAN undefined behavior warning has been reported for call to
> > ror32():
> > [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> > [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
>
> hm, do we care?
Hi Andrew,
Thank for reply.
We want to avoid UBSAN undefined behavior warning in case
"shift" parameter is not provided as a constant.
>
> > ...
> >
>
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
> > */
> > static inline __u64 ror64(__u64 word, unsigned int shift) {
> > + if (!shift)
> > + return word;
> > +
> > return (word >> shift) | (word << (64 - shift)); }
>
> Is there any known architecture or compiler for which UL<<64 doesn't reliably
> produce zero? Is there any prospect that this will become a problem in the
> future?
I don't know about such architecture.
Do you think it could be modified only for ro8, ror16, ror32?
On 09/04/2019 00.52, Andrew Morton wrote:
> (resend, cc Andrey)
>
> On Sun, 7 Apr 2019 12:53:25 +0000 Vadim Pasternak <[email protected]> wrote:
>
>> The warning is caused by call to rorXX(), if the second parameters of
>> this function "shift" is zero. In such case UBSAN reports the warning
>> for the next expression: (word << (XX - shift), where XX is
>> 64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
>> Fix adds validation of this parameter - in case it's equal zero, no
>> need to rotate, just original "word" is to be returned to caller.
>>
>> The UBSAN undefined behavior warning has been reported for call to
>> ror32():
>> [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
>> [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
>
> hm, do we care?
>
>> ...
>>
>
>> --- a/include/linux/bitops.h
>> +++ b/include/linux/bitops.h
>> @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
>> */
>> static inline __u64 ror64(__u64 word, unsigned int shift)
>> {
>> + if (!shift)
>> + return word;
>> +
>> return (word >> shift) | (word << (64 - shift));
>> }
>
> Is there any known architecture or compiler for which UL<<64 doesn't
> reliably produce zero? Is there any prospect that this will become a
> problem in the future?
There's a somewhat obscure platform called x86 which ignores anything
but the low 5 bits in %ecx for a shift instruction for a 32 bit shift
(and in 64 bit mode, the low 6 bits), so there the instruction foo << 64
would yield foo. Which is also ok in this case, of course, except for
the formal UB.
Now, there are other architectures that behave similarly, so one could do
u32 ror32(u32 x, unsigned s)
{
return (x >> (s&31)) | (x << ((32-s)&31));
}
to make the shifts always well-defined and also work as expected for s
>= 32... if only gcc recognized that the masking is redundant, so that
its "that's a ror" pattern detection could kick in. Unfortunately, it
seems that the above generates
0: 89 f1 mov %esi,%ecx
2: 89 f8 mov %edi,%eax
4: f7 d9 neg %ecx
6: d3 e0 shl %cl,%eax
8: 89 f1 mov %esi,%ecx
a: d3 ef shr %cl,%edi
c: 09 f8 or %edi,%eax
e: c3 retq
while without the masking one gets
10: 89 f8 mov %edi,%eax
12: 89 f1 mov %esi,%ecx
14: d3 c8 ror %cl,%eax
16: c3 retq
Rasmus
On 09/04/2019 10.08, Rasmus Villemoes wrote:
> one could do
>
> u32 ror32(u32 x, unsigned s)
> {
> return (x >> (s&31)) | (x << ((32-s)&31));
> }
>
> to make the shifts always well-defined and also work as expected for s
> >= 32... if only gcc recognized that the masking is redundant, so that
> its "that's a ror" pattern detection could kick in. Unfortunately, it
> seems that the above generates
>
> 0: 89 f1 mov %esi,%ecx
> 2: 89 f8 mov %edi,%eax
> 4: f7 d9 neg %ecx
> 6: d3 e0 shl %cl,%eax
> 8: 89 f1 mov %esi,%ecx
> a: d3 ef shr %cl,%edi
> c: 09 f8 or %edi,%eax
> e: c3 retq
>
> while without the masking one gets
>
> 10: 89 f8 mov %edi,%eax
> 12: 89 f1 mov %esi,%ecx
> 14: d3 c8 ror %cl,%eax
> 16: c3 retq
Ah, but that's with an ancient gcc 7. With gcc 8, the above pattern is
recognized and generates good code, while eliminating UB. I was about to
file a gcc bug, but found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 .
Rasmus
Hi!
> (resend, cc Andrey)
>
> On Sun, 7 Apr 2019 12:53:25 +0000 Vadim Pasternak <[email protected]> wrote:
>
> > The warning is caused by call to rorXX(), if the second parameters of
> > this function "shift" is zero. In such case UBSAN reports the warning
> > for the next expression: (word << (XX - shift), where XX is
> > 64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
> > Fix adds validation of this parameter - in case it's equal zero, no
> > need to rotate, just original "word" is to be returned to caller.
> >
> > The UBSAN undefined behavior warning has been reported for call to
> > ror32():
> > [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> > [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
>
> hm, do we care?
>
> > ...
> >
>
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
> > */
> > static inline __u64 ror64(__u64 word, unsigned int shift)
> > {
> > + if (!shift)
> > + return word;
> > +
> > return (word >> shift) | (word << (64 - shift));
> > }
>
> Is there any known architecture or compiler for which UL<<64 doesn't
> reliably produce zero? Is there any prospect that this will become a
> problem in the future?
Compiler is free to assume that shift !=0 after running ror64()... and
use that fact in optimalizations. so... if it is not problem today it
may easily become problem tommorow.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html