From: John Denker <jsd@av8n.com>
To: tytso@mit.edu, "H. Peter Anvin" <hpa@zytor.com>,
noloader@gmail.com, linux-kernel@vger.kernel.org,
Stephan Mueller <smueller@chronox.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
andi@firstfloor.org, Sandy Harris <sandyinchina@gmail.com>,
cryptography@lakedaemon.net, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG
Date: Wed, 4 May 2016 14:42:53 -0700 [thread overview]
Message-ID: <572A6CDD.10503@av8n.com> (raw)
In-Reply-To: <20160504190723.GD3901@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
On 05/04/2016 12:07 PM, tytso@thunk.org wrote:
> it doesn't hit the
> UB case which Jeffrey was concerned about.
That should be good enough for present purposes....
However, in the interests of long-term maintainability, I
would suggest sticking in a comment or assertion saying
that ror32(,shift) is never called with shift=0. This
can be removed if/when bitops.h is upgraded.
There is a track record of compilers doing Bad Things in
response to UB code, including some very counterintuitive
Bad Things.
On Wed, May 04, 2016 at 11:29:57AM -0700, H. Peter Anvin wrote:
>>
>> If bitops.h doesn't do the right thing, we need to
>> fix bitops.h.
Most of the ror and rol functions in linux/bitops.h
should be considered unsafe, as currently implemented.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/bitops.h?id=04974df8049fc4240d22759a91e035082ccd18b4#n103
I don't see anything in the file that suggests any limits
on the range of the second argument. So at best it is an
undocumented trap for the unwary. This has demonstrably
been a problem in the past. The explanation in the attached
fix-rol32.diff makes amusing reading.
Of the eight functions
ror64, rol64, ror32, rol32, ror16, rol16, ror8, and rol8,
only one of them can handle shifting by zero, namely rol32.
It was upgraded on Thu Dec 3 22:04:01 2015; see the attached
fix-rol32.diff.
I find it very odd that the other seven functions were not
upgraded. I suggest the attached fix-others.diff would make
things more consistent.
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior. This should be either documented
or fixed. It could be fixed easily enough.
[-- Attachment #2: fix-rol32.diff --]
[-- Type: text/x-patch, Size: 1858 bytes --]
commit d7e35dfa2531b53618b9e6edcd8752ce988ac555
Author: Sasha Levin <sasha.levin@oracle.com>
Date: Thu Dec 3 22:04:01 2015 -0500
bitops.h: correctly handle rol32 with 0 byte shift
ROL on a 32 bit integer with a shift of 32 or more is undefined and the
result is arch-dependent. Avoid this by handling the trivial case of
roling by 0 correctly.
The trivial solution of checking if shift is 0 breaks gcc's detection
of this code as a ROL instruction, which is unacceptable.
This bug was reported and fixed in GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157):
The standard rotate idiom,
(x << n) | (x >> (32 - n))
is recognized by gcc (for concreteness, I discuss only the case that x
is an uint32_t here).
However, this is portable C only for n in the range 0 < n < 32. For n
== 0, we get x >> 32 which gives undefined behaviour according to the
C standard (6.5.7, Bitwise shift operators). To portably support n ==
0, one has to write the rotate as something like
(x << n) | (x >> ((-n) & 31))
And this is apparently not recognized by gcc.
Note that this is broken on older GCCs and will result in slower ROL.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 2b8ed12..defeaac 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -107,7 +107,7 @@ static inline __u64 ror64(__u64 word, unsigned int shift)
*/
static inline __u32 rol32(__u32 word, unsigned int shift)
{
- return (word << shift) | (word >> (32 - shift));
+ return (word << shift) | (word >> ((-shift) & 31));
}
/**
[-- Attachment #3: fix-others.diff --]
[-- Type: text/x-patch, Size: 2488 bytes --]
commit 03b97eeb5401ede1e1d7b6fbf6a9575db8d0efa6
Author: John Denker <jsd@av8n.com>
Date: Wed May 4 13:55:51 2016 -0700
Make ror64, rol64, ror32, ror16, rol16, ror8, and rol8
consistent with rol32 in their handling of shifting by a zero amount.
Same overall rationale as in d7e35dfa, just more consistently applied.
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior. This should be either documented
or fixed. It could be fixed easily enough.
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index defeaac..97096b4 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -87,7 +87,7 @@ static __always_inline unsigned long hweight_long(unsigned long w)
*/
static inline __u64 rol64(__u64 word, unsigned int shift)
{
- return (word << shift) | (word >> (64 - shift));
+ return (word << shift) | (word >> ((-shift) & 64));
}
/**
@@ -97,7 +97,7 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
*/
static inline __u64 ror64(__u64 word, unsigned int shift)
{
- return (word >> shift) | (word << (64 - shift));
+ return (word >> shift) | (word << ((-shift) & 64));
}
/**
@@ -117,7 +117,7 @@ static inline __u32 rol32(__u32 word, unsigned int shift)
*/
static inline __u32 ror32(__u32 word, unsigned int shift)
{
- return (word >> shift) | (word << (32 - shift));
+ return (word >> shift) | (word << ((-shift) & 31));
}
/**
@@ -127,7 +127,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
*/
static inline __u16 rol16(__u16 word, unsigned int shift)
{
- return (word << shift) | (word >> (16 - shift));
+ return (word << shift) | (word >> ((-shift) & 16));
}
/**
@@ -137,7 +137,7 @@ static inline __u16 rol16(__u16 word, unsigned int shift)
*/
static inline __u16 ror16(__u16 word, unsigned int shift)
{
- return (word >> shift) | (word << (16 - shift));
+ return (word >> shift) | (word << ((-shift) & 16));
}
/**
@@ -147,7 +147,7 @@ static inline __u16 ror16(__u16 word, unsigned int shift)
*/
static inline __u8 rol8(__u8 word, unsigned int shift)
{
- return (word << shift) | (word >> (8 - shift));
+ return (word << shift) | (word >> ((-shift) & 8));
}
/**
@@ -157,7 +157,7 @@ static inline __u8 rol8(__u8 word, unsigned int shift)
*/
static inline __u8 ror8(__u8 word, unsigned int shift)
{
- return (word >> shift) | (word << (8 - shift));
+ return (word >> shift) | (word << ((-shift) & 8));
}
/**
next prev parent reply other threads:[~2016-05-04 21:49 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 6:26 [RFC PATCH 0/3] random: replace urandom pool with a CRNG Theodore Ts'o
2016-05-02 6:26 ` [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Theodore Ts'o
2016-05-03 8:50 ` Stephan Mueller
2016-05-04 16:54 ` Jeffrey Walton
2016-05-04 17:30 ` tytso
2016-05-04 17:52 ` H. Peter Anvin
2016-05-03 9:36 ` Stephan Mueller
2016-05-04 6:24 ` Stephan Mueller
2016-05-04 14:40 ` Jeffrey Walton
2016-05-04 17:49 ` tytso
2016-05-04 18:22 ` Jeffrey Walton
2016-05-04 18:29 ` H. Peter Anvin
2016-05-04 19:07 ` tytso
2016-05-04 20:53 ` H. Peter Anvin
2016-05-04 21:42 ` John Denker [this message]
2016-05-04 21:52 ` better patch for linux/bitops.h John Denker
2016-05-05 1:35 ` Jeffrey Walton
2016-05-05 2:41 ` H. Peter Anvin
2016-05-05 2:54 ` Jeffrey Walton
2016-05-05 3:08 ` H. Peter Anvin
2016-05-05 3:30 ` Jeffrey Walton
2016-05-05 3:50 ` Theodore Ts'o
2016-05-05 4:03 ` Jeffrey Walton
2016-05-05 6:35 ` H. Peter Anvin
2016-05-05 16:15 ` UB in general ... and linux/bitops.h in particular John Denker
2016-05-05 17:32 ` Andi Kleen
2016-05-06 2:25 ` Jeffrey Walton
2016-05-05 21:34 ` better patch for linux/bitops.h Sandy Harris
2016-05-05 22:18 ` tytso
2016-05-05 22:22 ` H. Peter Anvin
2016-05-05 22:38 ` H. Peter Anvin
2016-05-06 0:13 ` H. Peter Anvin
2016-05-04 21:56 ` [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG H. Peter Anvin
2016-05-04 22:06 ` linux/bitops.h John Denker
2016-05-04 23:06 ` linux/bitops.h Andi Kleen
2016-05-05 0:13 ` linux/bitops.h John Denker
2016-05-05 1:20 ` linux/bitops.h Jeffrey Walton
2016-05-05 1:27 ` linux/bitops.h H. Peter Anvin
2016-05-05 0:30 ` linux/bitops.h H. Peter Anvin
2016-05-05 0:48 ` linux/bitops.h Linus Torvalds
2016-05-06 20:08 ` linux/bitops.h Sasha Levin
2016-05-06 20:07 ` linux/bitops.h Sasha Levin
2016-05-06 20:25 ` linux/bitops.h H. Peter Anvin
2016-05-06 20:30 ` linux/bitops.h H. Peter Anvin
2016-05-02 6:26 ` [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o
2016-05-02 7:00 ` Stephan Mueller
2016-05-02 12:50 ` Theodore Ts'o
2016-05-02 13:48 ` Theodore Ts'o
2016-05-02 13:53 ` Stephan Mueller
2016-05-02 6:26 ` [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o
2016-05-02 9:00 ` Jeffrey Walton
2016-05-02 9:14 ` Stephan Mueller
2016-05-02 12:56 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572A6CDD.10503@av8n.com \
--to=jsd@av8n.com \
--cc=andi@firstfloor.org \
--cc=cryptography@lakedaemon.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noloader@gmail.com \
--cc=sandyinchina@gmail.com \
--cc=smueller@chronox.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.