grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: mchang@suse.com
Subject: Re: [PATCH] efi: Free malloc regions on exit
Date: Fri, 20 May 2016 06:56:21 +0300	[thread overview]
Message-ID: <573E8AE5.2060207@gmail.com> (raw)
In-Reply-To: <1463665072-32385-1-git-send-email-agraf@suse.de>

19.05.2016 16:37, Alexander Graf пишет:
> When we exit grub, we don't free all the memory that we allocated earlier
> for our heap region. This can cause problems with setups where you try
> to descend the boot order using "exit" entries, such as PXE -> HD boot
> scenarios.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  grub-core/kern/efi/init.c |  1 +
>  grub-core/kern/efi/mm.c   | 24 ++++++++++++++++++++++++
>  include/grub/efi/efi.h    |  1 +
>  3 files changed, 26 insertions(+)
> 
> diff --git a/grub-core/kern/efi/init.c b/grub-core/kern/efi/init.c
> index e9c85de..b848014 100644
> --- a/grub-core/kern/efi/init.c
> +++ b/grub-core/kern/efi/init.c
> @@ -77,4 +77,5 @@ grub_efi_fini (void)
>  {
>    grub_efidisk_fini ();
>    grub_console_fini ();
> +  grub_efi_memory_fini ();
>  }

Note that grub_efi_fini() is called not only during exit, but also by
grub_loader_boot (grub_machine_fini); and - at least, theoretically -
grub_loader_boot_func can fail and we return back to GRUB. Which leaves
us with heap pointing to already freed area. We probably cannot do
anything useful at this point anyway, but this may lead to corruption of
memory allocated by other EFI drivers.

May be it should be called explicitly only in exit path.

Also it is not called during chainload at all, which should have the
same problem (i.e. conceptually it does not matter whether we exit grub
and select next binary from EFI menu or simply try to chainload it from
grub).

> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index 20a47aa..4cd5971 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -49,6 +49,12 @@ static grub_efi_uintn_t finish_desc_size;
>  static grub_efi_uint32_t finish_desc_version;
>  int grub_efi_is_finished = 0;
>  
> +struct efi_allocation {
> +	grub_uint64_t start_addr;
> +	grub_uint64_t pages;
> +} efi_allocated_memory[16];
> +unsigned int efi_allocated_memory_idx = 0;
> +
>  /* Allocate pages. Return the pointer to the first of allocated pages.  */
>  void *
>  grub_efi_allocate_pages (grub_efi_physical_address_t address,
> @@ -408,6 +414,13 @@ add_memory_regions (grub_efi_memory_descriptor_t *memory_map,
>  		    (void *) ((grub_addr_t) start),
>  		    (unsigned) pages);
>  
> +      /* Track up to 16 regions that we allocate from */
> +      if (efi_allocated_memory_idx < ARRAY_SIZE(efi_allocated_memory)) {
> +        efi_allocated_memory[efi_allocated_memory_idx].start_addr = start;
> +        efi_allocated_memory[efi_allocated_memory_idx].pages = pages;
> +        efi_allocated_memory_idx++;
> +      }
> +

Can we walk regions list instead? May be we could store original address
and size in region descriptor?

>        grub_mm_init_region (addr, PAGES_TO_BYTES (pages));
>  
>        required_pages -= pages;

Hmm ... grub_mm_init_region may silently skip some regions. So this is
strictly speaking wrong (not related to your patch).

> @@ -419,6 +432,17 @@ add_memory_regions (grub_efi_memory_descriptor_t *memory_map,
>      grub_fatal ("too little memory");
>  }
>  
> +void
> +grub_efi_memory_fini (void)
> +{
> +  unsigned int i;
> +
> +  for (i = 0; i < efi_allocated_memory_idx; i++) {
> +    grub_efi_free_pages (efi_allocated_memory[i].start_addr,
> +                         efi_allocated_memory[i].pages);
> +  }
> +}
> +
>  #if 0
>  /* Print the memory map.  */
>  static void
> diff --git a/include/grub/efi/efi.h b/include/grub/efi/efi.h
> index 0e6fd86..545e7ce 100644
> --- a/include/grub/efi/efi.h
> +++ b/include/grub/efi/efi.h
> @@ -48,6 +48,7 @@ EXPORT_FUNC(grub_efi_get_memory_map) (grub_efi_uintn_t *memory_map_size,
>  				      grub_efi_uintn_t *map_key,
>  				      grub_efi_uintn_t *descriptor_size,
>  				      grub_efi_uint32_t *descriptor_version);
> +void grub_efi_memory_fini (void);
>  grub_efi_loaded_image_t *EXPORT_FUNC(grub_efi_get_loaded_image) (grub_efi_handle_t image_handle);
>  void EXPORT_FUNC(grub_efi_print_device_path) (grub_efi_device_path_t *dp);
>  char *EXPORT_FUNC(grub_efi_get_filename) (grub_efi_device_path_t *dp);
> 



  reply	other threads:[~2016-05-20  3:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 13:37 [PATCH] efi: Free malloc regions on exit Alexander Graf
2016-05-20  3:56 ` Andrei Borzenkov [this message]
2016-05-20  4:34   ` Michael Chang
2016-05-28  8:07     ` Andrei Borzenkov
2016-05-24  4:56 ` Elliott, Robert (Persistent Memory)
2016-05-27 14:16   ` Alexander Graf

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=573E8AE5.2060207@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=mchang@suse.com \
    /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;
as well as URLs for NNTP newsgroup(s).