Linux EFI development
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH v3 3/3] efi: random: combine bootloader provided RNG seed with RNG protocol output
Date: Thu, 20 Oct 2022 10:56:03 -0600	[thread overview]
Message-ID: <Y1F9oyE9QlJrzZNg@zx2c4.com> (raw)
In-Reply-To: <20221020083910.1902009-4-ardb@kernel.org>

Hi Ard,

Thanks for doing this. Some comments below:

On Thu, Oct 20, 2022 at 10:39:10AM +0200, Ard Biesheuvel wrote:
> Instead of blindly creating the EFI random seed configuration table if
> the RNG protocol is implemented and works, check whether such a EFI
> configuration table was provided by an earlier boot stage and if so,
> concatenate the existing and the new seeds, leaving it up to the core
> code to mix it in and credit it the way it sees fit.
> 
> This can be used for, e.g., systemd-boot, to pass an additional seed to
> Linux in a way that can be consumed by the kernel very early. In that
> case, the following definitions should be used to pass the seed to the
> EFI stub:
> 
> struct linux_efi_random_seed {
>       u32     size; // of the 'seed' array in bytes
>       u8      seed[];
> };
> 
> The memory for the struct must be allocated as EFI_ACPI_RECLAIM_MEMORY
> pool memory, and the address of the struct in memory should be installed
> as a EFI configuration table using the following GUID:
> 
> LINUX_EFI_RANDOM_SEED_TABLE_GUID        1ce1e5bc-7ceb-42f2-81e5-8aadf180f57b
> 
> Note that doing so is safe even on kernels that were built without this
> patch applied, but the seed will simply be overwritten with a seed
> derived from the EFI RNG protocol, if available. The recommended seed
> size is 32 bytes, anything beyond that is disregarded when the seeds are
> concatenated.

Since this commit message will be used by other implementers inevitably,
you might want to include something about forward secrecy, memzeroing
old allocations, etc.


> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

You can treat overwriting the old seed as an accidental bug, and Cc this
as stable like the rest of this series.

> +	/*
> +	 * Check whether a seed was provided by a prior boot stage. In that
> +	 * case, instead of overwriting it, let's create a new buffer that can
> +	 * hold both, and concatenate the existing and the new seeds.
> +	 */
> +	prev_seed = get_efi_config_table(LINUX_EFI_RANDOM_SEED_TABLE_GUID);
> +	if (prev_seed) {
> +		prev_seed_size = min(prev_seed->size, EFI_RANDOM_SEED_SIZE);
> +		seed_size += prev_seed_size;
> +	}

I think you can omit the min() here. If a bootloader passes a massive
seed such that allocations later fail, that's a bootloader problem, and
we should just complain loudly about it.

> +	seed->size = seed_size;
> +	if (prev_seed)
> +		memcpy(seed->bits + EFI_RANDOM_SEED_SIZE, prev_seed->bits,
> +		       prev_seed_size);

You memcpy here, but then:

> +
>  	status = efi_bs_call(install_configuration_table, &rng_table_guid, seed);
>  	if (status != EFI_SUCCESS)
>  		goto err_freepool;

If the installation here fails, you abort, leaving the memcpy'd seed in
memory without memzeroing.

>  
> +	if (prev_seed) {
> +		/* wipe and free the old seed if we managed to install the new one */
> +		memzero_explicit(prev_seed->bits, prev_seed_size);
> +		efi_bs_call(free_pool, prev_seed);
> +	}
>  	return EFI_SUCCESS;
>  
>  err_freepool:
> +	efi_warn("Failed to obtain seed from EFI_RNG_PROTOCOL%s\n",
> +		 prev_seed ? ", retaining bootloader supplied seed only" : "");

So maybe it makes sense to stick a memzero here too, just before
freeing?

Also, I don't think that efi_warn() makes sense. In the easy case, if
the bootloader provides a seed bu EFI doesn't have a RNG_PROTOCOL
implementation, then that's a firmware limitation the user likely can't
do anything about, in which case it's really good that systemd-boot is
providing something instead. So that's not something to worry about.
In the more complicated cases, you jump here when
install_configuration_table() fails, so that's something to warn about,
but perhaps just before goto. Then, you also return early from the
function up at the call to allocate_pool, so that'd be a place to warn
about too.

Not seen in this diff, but relevant too is that you currently exit early
from the function if locate_protocol fails. If there's a systemd-boot
seed already, this is premature. Instead, move the call to
locate_protocol down to just before the call to get_rng.

Jason

>  	efi_bs_call(free_pool, seed);
>  	return status;
>  }
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index cf96f8d5f15f..69454a7ccc6f 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1172,8 +1172,6 @@ void efi_check_for_embedded_firmwares(void);
>  static inline void efi_check_for_embedded_firmwares(void) { }
>  #endif
>  
> -efi_status_t efi_random_get_seed(void);
> -
>  #define arch_efi_call_virt(p, f, args...)	((p)->f(args))
>  
>  /*
> -- 
> 2.35.1
> 

  reply	other threads:[~2022-10-20 16:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20  8:39 [PATCH v3 0/3] efi: consume random seed provided by loader Ard Biesheuvel
2022-10-20  8:39 ` [PATCH v3 1/3] efi: random: reduce seed size to 32 bytes Ard Biesheuvel
2022-10-21  8:38   ` Ilias Apalodimas
2022-10-20  8:39 ` [PATCH v3 2/3] efi: random: Use 'ACPI reclaim' memory for random seed Ard Biesheuvel
2022-10-21  8:37   ` Ilias Apalodimas
2022-10-20  8:39 ` [PATCH v3 3/3] efi: random: combine bootloader provided RNG seed with RNG protocol output Ard Biesheuvel
2022-10-20 16:56   ` Jason A. Donenfeld [this message]
2022-10-20 17:11     ` Ard Biesheuvel
2022-10-20 17:22       ` Jason A. Donenfeld
2022-10-20 16:37 ` [PATCH v3 0/3] efi: consume random seed provided by loader Jason A. Donenfeld
2022-10-20 17:06   ` Ard Biesheuvel
2022-10-20 17:16     ` Jason A. Donenfeld
2022-10-20 17:27       ` Ard Biesheuvel
2022-10-20 17:35         ` Jason A. Donenfeld

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=Y1F9oyE9QlJrzZNg@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=lennart@poettering.net \
    --cc=linux-efi@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox