All of lore.kernel.org
 help / color / mirror / Atom feed
* Problem with loading 64-bit ELF image with multiboot2
@ 2013-07-22 11:46 Pawel Wojtalczyk
  2013-07-22 12:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 1 reply; 3+ messages in thread
From: Pawel Wojtalczyk @ 2013-07-22 11:46 UTC (permalink / raw)
  To: grub-devel

Hello,

I use x86 64-bit GRUB2 under EFI and would like to load 64-bit ELF 
image. The image looks as following:

$ 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


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: Problem with loading 64-bit ELF image with multiboot2
  2013-07-22 11:46 Problem with loading 64-bit ELF image with multiboot2 Pawel Wojtalczyk
@ 2013-07-22 12:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
  2013-07-22 13:28   ` Pawel Wojtalczyk
  0 siblings, 1 reply; 3+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-07-22 12:28 UTC (permalink / raw)
  To: The development of GNU GRUB

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
>



^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: Problem with loading 64-bit ELF image with multiboot2
  2013-07-22 12:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-07-22 13:28   ` Pawel Wojtalczyk
  0 siblings, 0 replies; 3+ messages in thread
From: Pawel Wojtalczyk @ 2013-07-22 13:28 UTC (permalink / raw)
  To: grub-devel

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
>
>



^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-07-22 13:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-22 11:46 Problem with loading 64-bit ELF image with multiboot2 Pawel Wojtalczyk
2013-07-22 12:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-07-22 13:28   ` Pawel Wojtalczyk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.