From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V1FEE-0006zq-Qt for mharc-grub-devel@gnu.org; Mon, 22 Jul 2013 08:28:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1FEA-0006uT-Lo for grub-devel@gnu.org; Mon, 22 Jul 2013 08:28:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1FE9-0005YA-63 for grub-devel@gnu.org; Mon, 22 Jul 2013 08:28:34 -0400 Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:55961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1FE9-0005Y0-0G for grub-devel@gnu.org; Mon, 22 Jul 2013 08:28:33 -0400 Received: by mail-ea0-f181.google.com with SMTP id a15so3836658eae.40 for ; Mon, 22 Jul 2013 05:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=znKS68aRSy9FcYJJFpWA25GeKxgyazXf+GueUF06RPI=; b=SqYmv38tUOzn3iwx0PbaKN5a/2pNAgZLzeUSmFKo+tRAsYFY24qOupJf9Yl3SZhfFJ yrjzJ9DXiome3iI8ANLA1u+LMEym4A9pKeVyGnsYcAlgurBdv9g10UVJ5NcrjrteAOSI H+6DWxMy81IJx2RYAbVSC+4qivdsMRAtUT/akKteQUJjZUdecT/6pY0Hkil6A5KPcDAm DeeEcrfzYJ3lELc0fg6ZUToJohy51ubiCf9yvgNpiv8QIbdOSQj5mVD46sgRPl4mqcNc dVukYmDB0nUYjp8MJGU6FRYMQxXae/Emu6SPXYCo6Zje1tz6n7ZZN77Xvw8ic2QudmNW csZA== X-Received: by 10.14.194.133 with SMTP id m5mr27607735een.109.1374496111790; Mon, 22 Jul 2013 05:28:31 -0700 (PDT) Received: from [192.168.1.113] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id m1sm50371164eex.17.2013.07.22.05.28.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 05:28:31 -0700 (PDT) Message-ID: <51ED2570.3040107@gmail.com> Date: Mon, 22 Jul 2013 14:28:32 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Problem with loading 64-bit ELF image with multiboot2 References: <51ED1B81.8000509@wp.pl> In-Reply-To: <51ED1B81.8000509@wp.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::235 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: Mon, 22 Jul 2013 12:28:37 -0000 On 22.07.2013 13:46, Pawel Wojtalczyk wrote: > Hello, > > I use x86 64-bit GRUB2 under EFI and would like to load 64-bit ELF > image. The image looks as following: > Rather than bringing the issue once more time in a different place, look that this was already fixed in trunk. > $ objdump -h Image > > Image: file format elf64-x86-64 > > Sections: > Idx Name Size VMA LMA File > off Algn > 0 .text 0019d870 ffffffff90008000 0000000010008000 > 00000120 2**5 > CONTENTS, ALLOC, LOAD, CODE > 1 .wrs_build_vars 00000150 ffffffff901a5870 00000000101a5870 > 0019d990 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .data 0000db50 ffffffff901a59c0 00000000101a59c0 > 0019db00 2**6 > CONTENTS, ALLOC, LOAD, DATA > 3 .bss 01016e40 ffffffff901b3520 00000000101b3520 > 001ab660 2**5 > ALLOC > $ objdump -f Image > > Image: file format elf64-x86-64 > architecture: i386:x86-64, flags 0x00000012: > EXEC_P, HAS_SYMS > start address 0xffffffff90008000 > > I tried to load it via GRUB2, but unfortunately it displays 'invalid > entry point for ELF64'. The problem is that for 64-bit ELF images the > multiboot_elfxx.c library still requires 32-bit virtual address: > > #ifdef MULTIBOOT_LOAD_ELF64 > # if defined( __mips) > /* We still in 32-bit mode. */ > if (ehdr->e_entry < 0xffffffff80000000ULL) > return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64"); > # else > /* We still in 32-bit mode. */ > if (ehdr->e_entry > 0xffffffff) > return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64"); > # endif > #endif > > Could you tell me why this assumption is required? The virtual address > (e_entry is virtual following ELF specification) is related to the image > itself, how it setup MMU, not the loader (GRUB2). GRUB2 should check > only if the physical location of loaded image is in 32-bit physical memory. > > Besides if we skip thich e_entry check, the image is properly loaded, > because grub_multiboot_payload_eip is properly computed few lines below. > > grub_multiboot_payload_eip = (ehdr->e_entry - phdr(i)->p_vaddr) > + phdr(i)->p_paddr; > > Could you tell me why GRUB2 checks for 64-bit images this e_entry > virtual address (which can be everywhere in the 64-bit address space) > and requires it to be 32-bit address space only? > > Regards > Pawel Wojtalczyk > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >