bugGNU GRUB - Bugs: bug #39488, multiboot2 failed to load 64-bit...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #39488: multiboot2 failed to load 64-bit ELF image

Submitted by:  Paweł Wojtalczyk <eyak>
Submitted on:  Mon 15 Jul 2013 09:52:50 AM UTC  
 
Category: BootingSeverity: Major
Priority: 5 - NormalItem Group: Software Error
Status: InvalidPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: ClosedRelease: 
Release: Bazaar - trunkReproducibility: Every Time
Planned Release: None

Fri 19 Jul 2013 02:23:59 PM UTC, comment #5:

Hello,

Maybe we can do other way. Maybe we can skip checking e_entry, then 'invalid entry point for ELF64' message will be fixed for valid virtual address in canonical form (like ffffffff80000000), because the virtual address is more related to the loaded image itself rather to the GRUB2 (as loader). For GRUB2 more important is physical address where the image is loaded.

So maybe we can skip checking e_entry (as virtual) and add checking for grub_multiboot_payload_eip(as physical) if it is in 32-bit address space.

What do you think?

Best Regards
Leon

Paweł Wojtalczyk <eyak>
Wed 17 Jul 2013 04:08:06 AM UTC, comment #4:

Hello,

Move down from virtual to physical is properly done when calculate grub_multiboot_payload_eip few lines below. If e_entry would be physical (as current implementation GRUB2 assumes for everything else than MIPS) then the substraction physical address (e_entry) from virtual (p_vaddr) has no sense. The only one sense is when e_entry is also virtual (besides ELF specification explicity describes that). So e_entry must be virtual.

I do not know why currently only for MIPS this assumption is done, but from ELF specification point of view e_entry is always virtual.

grub_multiboot_payload_eip = (ehdr->e_entry - phdr(i)->p_vaddr)
+ phdr(i)->p_paddr;

Best Regards
Leon

Paweł Wojtalczyk <eyak>
Tue 16 Jul 2013 04:29:48 PM UTC, comment #3:

It doesn't make the first part correct. The check is correct just needs to be moved down after v2p translation.

Vladimir Serbinenko <phcoder>
Project Administrator
Tue 16 Jul 2013 11:23:00 AM UTC, comment #2:

Hello Vladimir,

Thank you for your quick reponse and hints about LMA. You are right that it should point to physical address space instead of virtual.

But the first part of the bug report still needs to be applied to fix 'invalid entry point for ELF64' message. The reason is that following ELF specification (http://www.skyfree.org/linux/references/ELF_Format.pdf, page 10) entry address must point to virtual address space:

'e_entry - This member gives the virtual address to which the system first transfers control, thus
starting the process. If the file has no associated entry point, this member holds zero.'

So after apply this fix and change LMA to physical address, I can successfully start 64-bit ELF image.

Best Regards
Leon

Paweł Wojtalczyk <eyak>
Mon 15 Jul 2013 10:25:20 AM UTC, comment #1:

You need to put physical adresses in pheaders which are where you really want to load, not some transformation. If afterwards you shift your code virtually it's your problem, but pheaders must refer to real location.

Vladimir Serbinenko <phcoder>
Project Administrator
Mon 15 Jul 2013 09:52:50 AM UTC, original submission:

Hello,

I use 64-bit GRUB2 under x86_64 EFI and would like to load an 64-bit ELF images, but unfortunatelly 'invalid entry point for ELF64' message appears. To fix this issue in file multiboot_elfxx.c file the lines (in function grub_multiboot_load_elf()):

#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");

should be replaced with:

#ifdef MULTIBOOT_LOAD_ELF64
# if defined(__mips) || defined(__x86_64)
/* We still in 32-bit mode. */
if (ehdr->e_entry < 0xffffffff80000000ULL)
return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64");

Additionally under loaded 64-bit ELF image both virtual and physical addresses are encoded in canonical form address.

$ objdump -h Image

Image: file format elf64-x86-64

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 001e0cd0 ffffffff80608000 ffffffff80608000 00000080 2**5
CONTENTS, ALLOC, LOAD, CODE
1 .build_vars 00000150 ffffffff807e8cd0 ffffffff807e8cd0 001e0d50 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 000498d0 ffffffff807e8e40 ffffffff807e8e40 001e0ec0 2**6
CONTENTS, ALLOC, LOAD, DATA
3 .bss 0101b9e0 ffffffff80832720 ffffffff80832720 0022a790 2**5
ALLOC
4 .debug_aranges 00000cf0 0000000000000000 0000000000000000 0022a790 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_pubnames 00000d5c 0000000000000000 0000000000000000 0022b480 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_info 0000f50e 0000000000000000 0000000000000000 0022c1dc 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_abbrev 000041b7 0000000000000000 0000000000000000 0023b6ea 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_line 000048a0 0000000000000000 0000000000000000 0023f8a1 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_frame 00001948 0000000000000000 0000000000000000 00244148 2**3
CONTENTS, READONLY, DEBUGGING
10 .debug_str 00002c63 0000000000000000 0000000000000000 00245a90 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_loc 00013290 0000000000000000 0000000000000000 002486f3 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_ranges 00002980 0000000000000000 0000000000000000 0025b983 2**0
CONTENTS, READONLY, DEBUGGING

So the address should be cutted to 32-bit address space. It might be done with adding the code encapsulated with ifdefs also in grub_multiboot_load_elf function:

if (phdr(i)->p_type == PT_LOAD)
{
grub_err_t err;
void *source;
#ifdef MULTIBOOT_LOAD_ELF64
#ifdef (__x86_64)
phdr(i)->p_paddr &=0x7fffffff;
#endif /* defined(__x86_64) */
#endif /* MULTIBOOT_LOAD_ELF64 */

Is it possible to apply these changes for GRUB2 please. It would be very helpfully for x86_64 targets.
Thanks.

Best Regards
Leon

Paweł Wojtalczyk <eyak>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by phcoder (Posted a comment)
  • -unavailable- added by eyak (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 15 Jul 2013 10:25:20 AM UTCphcoderStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1