Linux EFI development
 help / color / mirror / Atom feed
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:56:23 +0000	[thread overview]
Message-ID: <20150212105623.GC1522@leverpostej> (raw)
In-Reply-To: <CAKv+Gu88vzPpXoSEs1ZSQbO7wsqh7NRSZc=iSpC9D6vzus7f8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, Feb 12, 2015 at 10:39:46AM +0000, Ard Biesheuvel wrote:
> On 12 February 2015 at 18:22, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > 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.
> >
> 
> OK
> 
> >>        */
> >> -     *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?
> >
> 
> I don't see how doing a single allocation could result in a single
> free region to be split into more than 1 occupied region + 2 free
> regions.
> So no, I don't think it is ...

Fair enough. If we're surprised later we can always fix things up.

With the comment fix up:

Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>

Thanks,
Mark.

  parent reply	other threads:[~2015-02-12 10:56 UTC|newest]

Thread overview: 13+ 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
     [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 10:22   ` Mark Rutland
2015-02-12 10:39     ` Ard Biesheuvel
     [not found]       ` <CAKv+Gu88vzPpXoSEs1ZSQbO7wsqh7NRSZc=iSpC9D6vzus7f8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-12 10:56         ` Mark Rutland [this message]
2015-02-12 14:47         ` Matt Fleming
     [not found]           ` <20150212144727.GD4665-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
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:31                   ` Ard Biesheuvel
     [not found]                     ` <CAKv+Gu_Z0Upoy0J-hxf0i7Oen00tb-TENJ9CszdEtTHsb5pGSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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:34                           ` 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=20150212105623.GC1522@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox