From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ajV0W-0005o3-6d for mharc-grub-devel@gnu.org; Fri, 25 Mar 2016 12:54:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajV0T-0005nP-L1 for grub-devel@gnu.org; Fri, 25 Mar 2016 12:54:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajV0Q-0004gB-Eg for grub-devel@gnu.org; Fri, 25 Mar 2016 12:54:41 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:45098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajV0Q-0004g6-5y for grub-devel@gnu.org; Fri, 25 Mar 2016 12:54:38 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2PGsQC5029167 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 16:54:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2PGsPW2021006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 16:54:25 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2PGsMAY024720; Fri, 25 Mar 2016 16:54:22 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Mar 2016 09:54:21 -0700 Received: by char.us.oracle.com (Postfix, from userid 1000) id 06DAD6A00D2; Fri, 25 Mar 2016 12:54:19 -0400 (EDT) Date: Fri, 25 Mar 2016 12:54:19 -0400 From: Konrad Rzeszutek Wilk To: Daniel Kiper Subject: Re: [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images Message-ID: <20160325165419.GB20741@char.us.oracle.com> References: <1458320427-4653-1-git-send-email-daniel.kiper@oracle.com> <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 Cc: jgross@suse.com, grub-devel@gnu.org, eric.snowberg@oracle.com, arvidjaar@gmail.com, andrew.cooper3@citrix.com, stefano.stabellini@eu.citrix.com, cardoe@cardoe.com, pgnet.dev@gmail.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, jbeulich@suse.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org, seth.goldberg@oracle.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 16:54:42 -0000 On Fri, Mar 18, 2016 at 06:00:27PM +0100, Daniel Kiper wrote: > Currently multiboot2 protocol loads image exactly at address specified in > ELF or multiboot2 header. This solution works quite well on legacy BIOS > platforms. It is possible because memory regions are placed at predictable > addresses (though I was not able to find any spec which says that it is > strong requirement, so, it looks that it is just a goodwill of hardware > designers). However, EFI platforms are more volatile. Even if required > memory regions live at specific addresses then they are sometimes simply > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and > OVMF). This means that you are not able to just set up final image > destination on build time. You have to provide method to relocate image > contents to real load address which is usually different than load address > specified in ELF and multiboot2 headers. > > This patch provides all needed machinery to do self relocation in image code. > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr), > align (required image alignment), preference (it says which memory regions are > preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable > header tag contained in binary (at this stage load addresses from multiboot2 > and/or ELF headers are ignored). Later loader tries to fulfill request (not only > that one) and if it succeeds then it informs image about real load address via > multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting > from now executable must cope with relocations itself using whole static and > dynamic knowledge provided by boot loader. > > This patch does not provide functionality which could do relocations using > ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir > 'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery > could be added to existing code (including this patch) without huge effort. > Additionally, ELF relocation could live in parallel with self relocation provided > by this patch. However, during research I realized that first of all we should > establish the details how ELF relocatable image should look like and how it should > be build. At least to build proper test/example files. > > So, this patch just provides support for self relocatable images. If ELF file > with relocs is loaded then GRUB2 complains loudly and ignores it. Support for > such files will be added later. > > This patch was tested with Xen image which uses that functionality. However, this Xen > feature is still under development and new patchset will be released in about 3-4 weeks. > index e3a39b6..8a9ab0c 100644 > --- a/grub-core/loader/multiboot_elfxx.c > +++ b/grub-core/loader/multiboot_elfxx.c ..snip.. > static grub_err_t > -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, void *buffer) > +CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld) > { > +#ifdef MULTIBOOT_LOAD_ELF64 > + if (highest_load >= 0x100000000) > + return grub_error (GRUB_ERR_BAD_OS, "segment cross 4 GiB border"); segment crosses 4GiB border!