From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V1GAa-0000fq-Kx for mharc-grub-devel@gnu.org; Mon, 22 Jul 2013 09:28:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1GAR-0000Yx-4S for grub-devel@gnu.org; Mon, 22 Jul 2013 09:28:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1GAM-0003co-HO for grub-devel@gnu.org; Mon, 22 Jul 2013 09:28:47 -0400 Received: from mx4.wp.pl ([212.77.101.8]:17362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1GAM-0003cK-5x for grub-devel@gnu.org; Mon, 22 Jul 2013 09:28:42 -0400 Received: (wp-smtpd smtp.wp.pl 19014 invoked from network); 22 Jul 2013 15:28:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1374499719; bh=EBYnImgcZXABNGR5+yfEVvNfr90qDrTUMcDZ/8qh8PM=; h=From:To:Subject; b=nsLeyRoVyxIZqhf3b57335DBpblS9BtRlZJ9n6atybrqtwoUr/l8nbSzjmVOehNgF 7DVt8w1We/NeAldRaSed0oYzgf5HL8U4BrzWeEpYrorIqQ7qkTQoaONnUt9nTMjf3W rw/vuy4iu1cljHbIAWl9twCj8x1XF2y6ON6KYEqY= Received: from mail.kontron.pl (eyak@[217.153.153.212]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 22 Jul 2013 15:28:39 +0200 Message-ID: <51ED3387.6060901@wp.pl> Date: Mon, 22 Jul 2013 15:28:39 +0200 From: Pawel Wojtalczyk MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Problem with loading 64-bit ELF image with multiboot2 References: <51ED1B81.8000509@wp.pl> <51ED2570.3040107@gmail.com> In-Reply-To: <51ED2570.3040107@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [wXM0] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.77.101.8 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 13:28:55 -0000 Hello Vladimir, I just do not understand current implementation and would not discuss as a bug, because you rejected this issue as a bug. But I see that you have modified the code to allow loading 64-bit ELFs linked in high address and did not received the notification about it. Thank you. Regards Pawel On 22.07.2013 14:28, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > 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 >> > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > >