diff mbox series

efi/arm64: Update debug prints to reflect other entropy sources

Message ID 20210119170742.20969-1-broonie@kernel.org
State Superseded
Headers show
Series efi/arm64: Update debug prints to reflect other entropy sources | expand

Commit Message

Mark Brown Jan. 19, 2021, 5:07 p.m. UTC
Currently the EFI stub prints a diagnostic on boot saying that KASLR will
be disabled if it is unable to use the EFI RNG protocol to obtain a seed
for KASLR. When this code was originally added there were no other entropy
sources which KASLR would be able to obtain entropy from so this was
accurate but with the addition of support of v8.5-RNG and the SMCCC RNG
protocol it is now possible for KASLR to obtain entropy even if the EFI
RNG protocol is unsupported in the system. This has been seen in emulated
systems with EFI.

Weaken the diagnostic to reflect the fact that KASLR may not be disabled,
the warning is still useful as other sources may not be available and newer
versions of both SBBR and EBBR require the RNG protocol and recommend that
it be able to provide sufficient entropy for seeding KASLR.

Signed-off-by: Mark Brown <broonie@kernel.org>

---
 drivers/firmware/efi/libstub/arm64-stub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.20.1

Comments

Ard Biesheuvel Jan. 20, 2021, 8:39 a.m. UTC | #1
On Tue, 19 Jan 2021 at 19:26, Mark Brown <broonie@kernel.org> wrote:
>

> Currently the EFI stub prints a diagnostic on boot saying that KASLR will

> be disabled if it is unable to use the EFI RNG protocol to obtain a seed

> for KASLR. When this code was originally added there were no other entropy

> sources which KASLR would be able to obtain entropy from so this was

> accurate but with the addition of support of v8.5-RNG and the SMCCC RNG

> protocol it is now possible for KASLR to obtain entropy even if the EFI

> RNG protocol is unsupported in the system. This has been seen in emulated

> systems with EFI.

>

> Weaken the diagnostic to reflect the fact that KASLR may not be disabled,

> the warning is still useful as other sources may not be available and newer

> versions of both SBBR and EBBR require the RNG protocol and recommend that

> it be able to provide sufficient entropy for seeding KASLR.

>

> Signed-off-by: Mark Brown <broonie@kernel.org>

> ---

>  drivers/firmware/efi/libstub/arm64-stub.c | 4 ++--

>  1 file changed, 2 insertions(+), 2 deletions(-)

>

> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c

> index 22ece1ad68a8..94ade08b1054 100644

> --- a/drivers/firmware/efi/libstub/arm64-stub.c

> +++ b/drivers/firmware/efi/libstub/arm64-stub.c

> @@ -61,10 +61,10 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,

>                         status = efi_get_random_bytes(sizeof(phys_seed),

>                                                       (u8 *)&phys_seed);

>                         if (status == EFI_NOT_FOUND) {

> -                               efi_info("EFI_RNG_PROTOCOL unavailable, KASLR will be disabled\n");

> +                               efi_info("EFI_RNG_PROTOCOL unavailable, KASLR may be disabled\n");

>                                 efi_nokaslr = true;

>                         } else if (status != EFI_SUCCESS) {

> -                               efi_err("efi_get_random_bytes() failed (0x%lx), KASLR will be disabled\n",

> +                               efi_err("efi_get_random_bytes() failed (0x%lx), KASLR may be disabled\n",

>                                         status);

>                                 efi_nokaslr = true;

>                         }

> --

> 2.20.1

>


The EFI stub randomizes the physical placement of the kernel as well,
and this is no longer possible by the time we reach early_kaslr_init()
in the kernel proper, so this is not something RNDR et al can make up
for.

So perhaps change this to 'physical placement will not be randomized'
or something along those lines? Or alternatively, just remove the
second part of the sentence - we have better reporting of the KASLR
state now anyway.
Mark Brown Jan. 20, 2021, 4:28 p.m. UTC | #2
On Wed, Jan 20, 2021 at 09:39:27AM +0100, Ard Biesheuvel wrote:

> The EFI stub randomizes the physical placement of the kernel as well,

> and this is no longer possible by the time we reach early_kaslr_init()

> in the kernel proper, so this is not something RNDR et al can make up

> for.


Ah, I'd not seen that the stub also did physical randomization.

> So perhaps change this to 'physical placement will not be randomized'

> or something along those lines? Or alternatively, just remove the

> second part of the sentence - we have better reporting of the KASLR

> state now anyway.


Probably easier to just remove it rather than bikeshed the log message,
it flags the error and avoids the issue I was seeing where the
diagnostics in the boot log claimed that we had both disabled and
enabled KASLR (quantum KASLR!).
diff mbox series

Patch

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 22ece1ad68a8..94ade08b1054 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -61,10 +61,10 @@  efi_status_t handle_kernel_image(unsigned long *image_addr,
 			status = efi_get_random_bytes(sizeof(phys_seed),
 						      (u8 *)&phys_seed);
 			if (status == EFI_NOT_FOUND) {
-				efi_info("EFI_RNG_PROTOCOL unavailable, KASLR will be disabled\n");
+				efi_info("EFI_RNG_PROTOCOL unavailable, KASLR may be disabled\n");
 				efi_nokaslr = true;
 			} else if (status != EFI_SUCCESS) {
-				efi_err("efi_get_random_bytes() failed (0x%lx), KASLR will be disabled\n",
+				efi_err("efi_get_random_bytes() failed (0x%lx), KASLR may be disabled\n",
 					status);
 				efi_nokaslr = true;
 			}