From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1b3bY7-0008Fw-TG for mharc-grub-devel@gnu.org; Thu, 19 May 2016 23:56:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3bY6-0008Fm-6X for grub-devel@gnu.org; Thu, 19 May 2016 23:56:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3bY1-00054o-9N for grub-devel@gnu.org; Thu, 19 May 2016 23:56:30 -0400 Received: from mail-lb0-x242.google.com ([2a00:1450:4010:c04::242]:34083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3bY0-00053A-SE for grub-devel@gnu.org; Thu, 19 May 2016 23:56:25 -0400 Received: by mail-lb0-x242.google.com with SMTP id bg8so4913432lbc.1 for ; Thu, 19 May 2016 20:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bfbh7sHMPKUCxrdxhd8aE8dhSnOMtFO/mgtgRi3Nmbg=; b=dR5qJHISgbgal4QWqnslKTxziym09fS1QLJCTaYqfjpFna4l/losH3n1N30B6kG/25 no8YrNXViCd4+DBo/RhATobygwod0SAcpO1TH+jelDGAWM234mvTZ6Co3NC77V6MM9eE BqHzQDH7Q7GlxQNLJCwCH/pIidLKVI108BhbeEsnn5OoFk0sshDdDdQCo2IEYMWJ/URk 15JP1Cp/OIZBephMYH2PWSmJObXn+XKdi96sZ4AmMVYBesjwhOCUH8L/fPO/eAy+uP1q C83rskYdnE7DanZftspiVYsNOotUx7a6rhl62QmKCUR5cWGCAEzVskE1sJ6YVJshW8uB KdRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bfbh7sHMPKUCxrdxhd8aE8dhSnOMtFO/mgtgRi3Nmbg=; b=WPDfS85ECe2EPxRAvb5mwMpsS4xfRgzySD5BTKiJpbv+rJIFBZeYrIkdKUQ2VbwdK/ 3g70WCrCIH3CxY0FHJBpkiHv4YPtclP6+jBv5DamuCMwOG7iHenbLJaifxUY4/KAKS8V MLkiL3f590OSgvfuOwxT8GREsM2NdDFY3ZAzgeQ7okyGgd25seiAz1X6MtRI0S7nQkCu p0zdw4RRKy0256l3qHLrlzp7FZrpB0ghSqbC4kQwqX3eVFMTBnC5+pyXRl2K9mOXXbpO VW0unbpdu8qvyZBJRuXc3SE3nr0xaMMbPIN2g1h9H0Df4ZF+PYbbIPor6mM/pQ0xWT3U e1Yg== X-Gm-Message-State: AOPr4FXB+Vy8YOGLimtynKnpf4rPQRPeVUb4TGHEZxIeE5/uXMg81IYwoNUIdn1ToJ90zA== X-Received: by 10.112.169.105 with SMTP id ad9mr263566lbc.123.1463716583383; Thu, 19 May 2016 20:56:23 -0700 (PDT) Received: from [192.168.1.42] (ppp109-252-90-46.pppoe.spdop.ru. [109.252.90.46]) by smtp.gmail.com with ESMTPSA id z21sm2968937lff.0.2016.05.19.20.56.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 20:56:22 -0700 (PDT) Subject: Re: [PATCH] efi: Free malloc regions on exit To: The development of GNU GRUB References: <1463665072-32385-1-git-send-email-agraf@suse.de> Cc: mchang@suse.com From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <573E8AE5.2060207@gmail.com> Date: Fri, 20 May 2016 06:56:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1463665072-32385-1-git-send-email-agraf@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::242 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 03:56:31 -0000 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 > --- > 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); >