2022-08-17 09:51:02

by Andrea Righi

[permalink] [raw]
Subject: [PATCH] arm64: head: rely on CONFIG_RANDOM_TRUST_CPU

The CONFIG_ARCH_RANDOM .config option has been removed by
commit 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM").

Depend on CONFIG_RANDOM_TRUST_CPU to determine whether we can rely on
__arm64_rndr() to initialize the seed for kaslr.

Fixes: 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM")
Signed-off-by: Andrea Righi <[email protected]>
---
arch/arm64/kernel/pi/kaslr_early.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/pi/kaslr_early.c b/arch/arm64/kernel/pi/kaslr_early.c
index 6c3855e69395..a1e6f90cb6e2 100644
--- a/arch/arm64/kernel/pi/kaslr_early.c
+++ b/arch/arm64/kernel/pi/kaslr_early.c
@@ -94,7 +94,7 @@ asmlinkage u64 kaslr_early_init(void *fdt)

seed = get_kaslr_seed(fdt);
if (!seed) {
-#ifdef CONFIG_ARCH_RANDOM
+#ifdef CONFIG_RANDOM_TRUST_CPU
if (!__early_cpu_has_rndr() ||
!__arm64_rndr((unsigned long *)&seed))
#endif
--
2.34.1


2022-08-17 13:46:52

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH] arm64: head: rely on CONFIG_RANDOM_TRUST_CPU

On Wed, Aug 17, 2022 at 11:46:18AM +0200, Andrea Righi wrote:
> The CONFIG_ARCH_RANDOM .config option has been removed by
> commit 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM").
>
> Depend on CONFIG_RANDOM_TRUST_CPU to determine whether we can rely on
> __arm64_rndr() to initialize the seed for kaslr.
>
> Fixes: 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM")

> -#ifdef CONFIG_ARCH_RANDOM
> +#ifdef CONFIG_RANDOM_TRUST_CPU
> if (!__early_cpu_has_rndr() ||
> !__arm64_rndr((unsigned long *)&seed))
> #endif

I think the sense here would be more that we should just unconditionally
use RNDR if it's present - previously we'd use the result even if we
didn't have strong trust in the CPU implementation and I don't see why
we'd want to change that.


Attachments:
(No filename) (791.00 B)
signature.asc (499.00 B)
Download all attachments

2022-08-17 14:18:06

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH] arm64: head: rely on CONFIG_RANDOM_TRUST_CPU

On Wed, Aug 17, 2022 at 11:46:18AM +0200, Andrea Righi wrote:
> The CONFIG_ARCH_RANDOM .config option has been removed by
> commit 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM").
>
> Depend on CONFIG_RANDOM_TRUST_CPU to determine whether we can rely on
> __arm64_rndr() to initialize the seed for kaslr.
>
> Fixes: 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM")
> Signed-off-by: Andrea Righi <[email protected]>
> ---
> arch/arm64/kernel/pi/kaslr_early.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/pi/kaslr_early.c b/arch/arm64/kernel/pi/kaslr_early.c
> index 6c3855e69395..a1e6f90cb6e2 100644
> --- a/arch/arm64/kernel/pi/kaslr_early.c
> +++ b/arch/arm64/kernel/pi/kaslr_early.c
> @@ -94,7 +94,7 @@ asmlinkage u64 kaslr_early_init(void *fdt)
>
> seed = get_kaslr_seed(fdt);
> if (!seed) {
> -#ifdef CONFIG_ARCH_RANDOM
> +#ifdef CONFIG_RANDOM_TRUST_CPU
> if (!__early_cpu_has_rndr() ||
> !__arm64_rndr((unsigned long *)&seed))
> #endif

There was another patch sent for this which just removed the guard
altogether:

https://lore.kernel.org/r/[email protected]

I was planning to pick that one up as a fix for -rc2 as Ard was happy
with it and it matches what Broonie was after as well.

Will

2022-08-17 14:40:35

by Andrea Righi

[permalink] [raw]
Subject: Re: [PATCH] arm64: head: rely on CONFIG_RANDOM_TRUST_CPU

On Wed, Aug 17, 2022 at 02:16:28PM +0100, Mark Brown wrote:
> On Wed, Aug 17, 2022 at 11:46:18AM +0200, Andrea Righi wrote:
> > The CONFIG_ARCH_RANDOM .config option has been removed by
> > commit 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM").
> >
> > Depend on CONFIG_RANDOM_TRUST_CPU to determine whether we can rely on
> > __arm64_rndr() to initialize the seed for kaslr.
> >
> > Fixes: 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM")
>
> > -#ifdef CONFIG_ARCH_RANDOM
> > +#ifdef CONFIG_RANDOM_TRUST_CPU
> > if (!__early_cpu_has_rndr() ||
> > !__arm64_rndr((unsigned long *)&seed))
> > #endif
>
> I think the sense here would be more that we should just unconditionally
> use RNDR if it's present - previously we'd use the result even if we
> didn't have strong trust in the CPU implementation and I don't see why
> we'd want to change that.

Makes sense, in that case it'd be better to just remove the guard
completely, as mentioned by Will.

Thanks,
-Andrea