From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors
Date: Thu, 12 Feb 2015 10:22:27 +0000 [thread overview]
Message-ID: <20150212102226.GB1245@leverpostej> (raw)
In-Reply-To: <1423718659-795-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Feb 12, 2015 at 05:24:19AM +0000, Ard Biesheuvel wrote:
> As it turns out, when allocating room for the UEFI memory map using
> UEFI's AllocatePool (), it may result in two new memory map entries
> being created, for instance, when using Tianocore's preallocated region
> feature. For example, the following region
>
> 0x00005ead5000-0x00005ebfffff [Conventional Memory| | | | | |WB|WT|WC|UC]
>
> may be split like this
>
> 0x00005ead5000-0x00005eae2fff [Conventional Memory| | | | | |WB|WT|WC|UC]
> 0x00005eae3000-0x00005eae4fff [Loader Data | | | | | |WB|WT|WC|UC]
> 0x00005eae5000-0x00005ebfffff [Conventional Memory| | | | | |WB|WT|WC|UC]
>
> if the preallocated Loader Data region was chosen to be right in the
> middle of the original free space.
>
> After patch d1a8d66b9177 ("efi/libstub: Call get_memory_map() to
> obtain map and desc sizes"), this is not being dealt with correctly
> anymore, as the existing logic to allocate room for a single additional
> entry has become insufficient.
>
> So instead, add room for two additional entries instead.
>
> Fixes: d1a8d66b9177 ("efi/libstub: Call get_memory_map() to obtain map and desc sizes")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index af5d63c7cc53..ca0b07ed3b14 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -84,10 +84,10 @@ efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
> return EFI_LOAD_ERROR;
>
> /*
> - * Add an additional efi_memory_desc_t because we're doing an
> - * allocation which may be in a new descriptor region.
> + * Add room for two additional efi_memory_desc_t entries because we're
> + * doing an allocation which may be in a new descriptor region.
It might be worth noting that a existing regions can be
split/reorganised here, otherwise it's a little difficult to deduce from
the comment why to regions are needed.
> */
> - *map_size += *desc_size;
> + *map_size += *desc_size * 2;
Can we forsee any cases where we might need more than two additional
descs? Is it perhaps adding a little more slack now?
Otherwise this looks fine to me.
Thanks,
Mark.
> status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> *map_size, (void **)&m);
> if (status != EFI_SUCCESS)
> --
> 1.8.3.2
>
>
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors
Date: Thu, 12 Feb 2015 10:22:27 +0000 [thread overview]
Message-ID: <20150212102226.GB1245@leverpostej> (raw)
In-Reply-To: <1423718659-795-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Feb 12, 2015 at 05:24:19AM +0000, Ard Biesheuvel wrote:
> As it turns out, when allocating room for the UEFI memory map using
> UEFI's AllocatePool (), it may result in two new memory map entries
> being created, for instance, when using Tianocore's preallocated region
> feature. For example, the following region
>
> 0x00005ead5000-0x00005ebfffff [Conventional Memory| | | | | |WB|WT|WC|UC]
>
> may be split like this
>
> 0x00005ead5000-0x00005eae2fff [Conventional Memory| | | | | |WB|WT|WC|UC]
> 0x00005eae3000-0x00005eae4fff [Loader Data | | | | | |WB|WT|WC|UC]
> 0x00005eae5000-0x00005ebfffff [Conventional Memory| | | | | |WB|WT|WC|UC]
>
> if the preallocated Loader Data region was chosen to be right in the
> middle of the original free space.
>
> After patch d1a8d66b9177 ("efi/libstub: Call get_memory_map() to
> obtain map and desc sizes"), this is not being dealt with correctly
> anymore, as the existing logic to allocate room for a single additional
> entry has become insufficient.
>
> So instead, add room for two additional entries instead.
>
> Fixes: d1a8d66b9177 ("efi/libstub: Call get_memory_map() to obtain map and desc sizes")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index af5d63c7cc53..ca0b07ed3b14 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -84,10 +84,10 @@ efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
> return EFI_LOAD_ERROR;
>
> /*
> - * Add an additional efi_memory_desc_t because we're doing an
> - * allocation which may be in a new descriptor region.
> + * Add room for two additional efi_memory_desc_t entries because we're
> + * doing an allocation which may be in a new descriptor region.
It might be worth noting that a existing regions can be
split/reorganised here, otherwise it's a little difficult to deduce from
the comment why to regions are needed.
> */
> - *map_size += *desc_size;
> + *map_size += *desc_size * 2;
Can we forsee any cases where we might need more than two additional
descs? Is it perhaps adding a little more slack now?
Otherwise this looks fine to me.
Thanks,
Mark.
> status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> *map_size, (void **)&m);
> if (status != EFI_SUCCESS)
> --
> 1.8.3.2
>
>
next prev parent reply other threads:[~2015-02-12 10:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 5:24 [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors Ard Biesheuvel
2015-02-12 5:24 ` Ard Biesheuvel
[not found] ` <1423718659-795-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-02-12 8:21 ` Roy Franz
2015-02-12 8:21 ` Roy Franz
2015-02-12 10:22 ` Mark Rutland [this message]
2015-02-12 10:22 ` Mark Rutland
2015-02-12 10:39 ` Ard Biesheuvel
2015-02-12 10:39 ` Ard Biesheuvel
[not found] ` <CAKv+Gu88vzPpXoSEs1ZSQbO7wsqh7NRSZc=iSpC9D6vzus7f8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-12 10:56 ` Mark Rutland
2015-02-12 10:56 ` Mark Rutland
2015-02-12 14:47 ` Matt Fleming
2015-02-12 14:47 ` Matt Fleming
[not found] ` <20150212144727.GD4665-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-02-12 14:56 ` Ard Biesheuvel
2015-02-12 14:56 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-NAKASZc4phj5x83mB8Ak4Gy2zYq-a0CDADEOTBD4pXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-12 15:16 ` Mark Rutland
2015-02-12 15:16 ` Mark Rutland
2015-02-12 15:31 ` Ard Biesheuvel
2015-02-12 15:31 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_Z0Upoy0J-hxf0i7Oen00tb-TENJ9CszdEtTHsb5pGSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-13 16:04 ` Matt Fleming
2015-02-13 16:04 ` Matt Fleming
[not found] ` <20150213160448.GA30567-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-02-13 16:23 ` Ard Biesheuvel
2015-02-13 16:23 ` Ard Biesheuvel
2015-02-13 16:34 ` Mark Rutland
2015-02-13 16:34 ` Mark Rutland
2015-02-13 16:33 ` Mark Rutland
2015-02-13 16:33 ` Mark Rutland
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=20150212102226.GB1245@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 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.