From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:29
This is a resend of a series from Richard Henderson last posted back in
November:
https://lore.kernel.org/linux-arm-kernel/20191106141308.30535-1-rth@twiddle.net/
Back then Borislav said they looked good and asked if he should take
them through the tip tree but things seem to have got lost since then.
Original cover letter:
During patch review for an addition of archrandom.h for arm64, it was
suggeted that the arch_random_get_* functions should be marked __must_check.
Which does sound like a good idea, since the by-reference integer output
may be uninitialized when the boolean result is false.
In addition, it turns out that arch_has_random() and arch_has_random_seed()
are not used, and not easy to support for arm64. Rather than cobble
something together that would not be testable, remove the interfaces
against some future accidental use.
In addition, I noticed a few other minor inconsistencies between the
different architectures, e.g. powerpc isn't using bool.
Change since v1:
* Remove arch_has_random, arch_has_random_seed.
Richard Henderson (10):
x86: Remove arch_has_random, arch_has_random_seed
powerpc: Remove arch_has_random, arch_has_random_seed
s390: Remove arch_has_random, arch_has_random_seed
linux/random.h: Remove arch_has_random, arch_has_random_seed
linux/random.h: Use false with bool
linux/random.h: Mark CONFIG_ARCH_RANDOM functions __must_check
x86: Mark archrandom.h functions __must_check
powerpc: Use bool in archrandom.h
powerpc: Mark archrandom.h functions __must_check
s390x: Mark archrandom.h functions __must_check
arch/powerpc/include/asm/archrandom.h | 27 +++++++++-----------------
arch/s390/include/asm/archrandom.h | 20 ++++---------------
arch/x86/include/asm/archrandom.h | 28 ++++++++++++---------------
include/linux/random.h | 24 ++++++++---------------
4 files changed, 33 insertions(+), 66 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:31
From: Richard Henderson <richard.henderson@linaro.org>
Use the expansion of these macros directly in arch_get_random_*.
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/x86/include/asm/archrandom.h | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
@@ -73,10 +73,6 @@ static inline bool rdseed_int(unsigned int *v)returnok;}-/* Conditional execution based on CPU type */-#define arch_has_random() static_cpu_has(X86_FEATURE_RDRAND)-#define arch_has_random_seed() static_cpu_has(X86_FEATURE_RDSEED)-/**Thesearethegenericinterfaces;theymustnotbedeclaredifthe*stubsin<linux/random.h>aretobeinvoked,
@@ -86,22 +82,22 @@ static inline bool rdseed_int(unsigned int *v)staticinlineboolarch_get_random_long(unsignedlong*v){-returnarch_has_random()?rdrand_long(v):false;+returnstatic_cpu_has(X86_FEATURE_RDRAND)?rdrand_long(v):false;}staticinlineboolarch_get_random_int(unsignedint*v){-returnarch_has_random()?rdrand_int(v):false;+returnstatic_cpu_has(X86_FEATURE_RDRAND)?rdrand_int(v):false;}staticinlineboolarch_get_random_seed_long(unsignedlong*v){-returnarch_has_random_seed()?rdseed_long(v):false;+returnstatic_cpu_has(X86_FEATURE_RDSEED)?rdseed_long(v):false;}staticinlineboolarch_get_random_seed_int(unsignedint*v){-returnarch_has_random_seed()?rdseed_int(v):false;+returnstatic_cpu_has(X86_FEATURE_RDSEED)?rdseed_int(v):false;}externvoidx86_init_rdrand(structcpuinfo_x86*c);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:34
From: Richard Henderson <richard.henderson@linaro.org>
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/powerpc/include/asm/archrandom.h | 10 ----------
1 file changed, 10 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:36
From: Richard Henderson <richard.henderson@linaro.org>
These symbols are currently part of the generic archrandom.h
interface, but are currently unused and can be removed.
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/s390/include/asm/archrandom.h | 12 ------------
1 file changed, 12 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:37
From: Richard Henderson <richard.henderson@linaro.org>
The arm64 version of archrandom.h will need to be able to test for
support and read the random number without preemption, so a separate
query predicate is not practical.
Since this part of the generic interface is unused, remove it.
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/linux/random.h | 8 --------
1 file changed, 8 deletions(-)
@@ -175,10 +175,6 @@ static inline bool arch_get_random_int(unsigned int *v){return0;}-staticinlineboolarch_has_random(void)-{-return0;-}staticinlineboolarch_get_random_seed_long(unsignedlong*v){return0;
@@ -187,10 +183,6 @@ static inline bool arch_get_random_seed_int(unsigned int *v){return0;}-staticinlineboolarch_has_random_seed(void)-{-return0;-}#endif/* Pseudo random number generator from numerical recipes. */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:42
From: Richard Henderson <richard.henderson@linaro.org>
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/linux/random.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:46
From: Richard Henderson <richard.henderson@linaro.org>
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/x86/include/asm/archrandom.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:51
From: Richard Henderson <richard.henderson@linaro.org>
We must not use the pointer output without validating the
success of the random read.
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/s390/include/asm/archrandom.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:54
From: Richard Henderson <richard.henderson@linaro.org>
We must not use the pointer output without validating the
success of the random read.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/powerpc/include/asm/archrandom.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Mark Brown <broonie@kernel.org> Date: 2020-01-10 14:54:56
From: Richard Henderson <richard.henderson@linaro.org>
Keep the generic fallback versions in sync with the other architecture
specific implementations and use the proper name for false.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <redacted>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/linux/random.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Or, alternatively, akpm could take them. In any case, if someone else
ends up doing that, for the x86 bits:
Reviewed-by: Borislav Petkov <redacted>
Or I can take them through the random.git tree, since we have a lot of
changes this cycle going to Linus anyway. Any objections?
- Ted
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Back then Borislav said they looked good and asked if he should take
them through the tip tree but things seem to have got lost since then.
quoted
Or, alternatively, akpm could take them. In any case, if someone else
ends up doing that, for the x86 bits:
Or I can take them through the random.git tree, since we have a lot of
changes this cycle going to Linus anyway. Any objections?
I think the important thing here is that *someone* takes the patches.
We've now got Ted and Borislav both saying they're OK applying the
patches, an additional proposal that Andrew takes the patches, nobody
saying anything negative about applying the patches and yet the patches
are not applied. The random tree sounds like a sensible enough tree to
take this so if Ted picks them up perhaps that's most sensible?
On Mon, Jan 20, 2020 at 05:26:27PM +0000, Mark Brown wrote:
I think the important thing here is that *someone* takes the patches.
We've now got Ted and Borislav both saying they're OK applying the
patches, an additional proposal that Andrew takes the patches, nobody
saying anything negative about applying the patches and yet the patches
are not applied. The random tree sounds like a sensible enough tree to
take this so if Ted picks them up perhaps that's most sensible?
From: "Theodore Y. Ts'o" <tytso@mit.edu> Date: 2020-01-25 17:47:16
On Mon, Jan 20, 2020 at 06:59:01PM +0100, Borislav Petkov wrote:
On Mon, Jan 20, 2020 at 05:26:27PM +0000, Mark Brown wrote:
quoted
I think the important thing here is that *someone* takes the patches.
We've now got Ted and Borislav both saying they're OK applying the
patches, an additional proposal that Andrew takes the patches, nobody
saying anything negative about applying the patches and yet the patches
are not applied. The random tree sounds like a sensible enough tree to
take this so if Ted picks them up perhaps that's most sensible?
Yes, Ted, pls pick them up so that we're done with this.