bugGNU GRUB - Bugs: bug #38800, x86-64: overflowing relocation...

 
 

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

bug #38800: x86-64: overflowing relocation crashes GRUB

Submitted by:  <qwertial>
Submitted on:  Mon 22 Apr 2013 05:46:08 AM UTC  
 
Category: NoneSeverity: Major
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: ClosedRelease: 
Release: Bazaar - trunkReproducibility: Every Time
Planned Release: None

Sat 04 May 2013 09:26:49 PM UTC, comment #5:

/usr/lib/grub is ro to user while the sceript improperly assumes the module directory to be writable. It's a problem with script. As for ->mod I'm puzzled as to why it works on my system as-is.

Vladimir Serbinenko <phcoder>
Project Administrator
Sat 04 May 2013 07:11:12 PM UTC, comment #4:

Ugh, Savannah ate my comment. (Though it is readable in the mailing list.) Anyway, it's because of this change:

http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/2445/kern/dl.c

The module list (to which grub_dl_head points) used to be implemented by two structures. The above change moved the "->next" pointer directly into the grub_dl structure and eliminated the other one.

(Also, the auto-attach-to-QEMU commands might be removed, as they are actually counterproductive when debugging grub-emu, and maybe the /usr/lib/grub/platform path prepended to module paths in gdb_grub.in and gmodule.pl.in... but that is another story.)

Has the original issue been addressed (pardon the pun) well enough to close this? There are no more crashes, by default at least.

<qwertial>
Tue 30 Apr 2013 02:43:21 AM UTC, comment #3:

grub-core/kern/dl.c:

<qwertial>
Mon 29 Apr 2013 05:19:22 PM UTC, comment #2:

Why do you need to remove ->mod ?

Vladimir Serbinenko <phcoder>
Project Administrator
Mon 22 Apr 2013 06:06:44 PM UTC, comment #1:

Some other random things discovered by the way:

0. grub-core/gdb_grub needs a correction for 64-bit pointers and data structures change:

1. FOR_LIST_ELEMENTS_SAFE is not as safe as it says: it will dereference the final NULL pointer after assigning it to var. Which is mostly harmless without memory protection, but crashes grub-emu running the help command.

2. Speaking of which, running "help help" crashes because the help command was registered with a 0 pointer for the parser argument. The NULL check in grub_arg_show_help() happens too late. This does not seem to do much on real hardware, though it may access some bogus data.

<qwertial>
Mon 22 Apr 2013 05:46:08 AM UTC, original submission:

The x86-64 version of grub_arch_dl_relocate_symbols() does not check whether an R_X86_64_PC32 relocation fits into 32 bits. This makes grub-emu-lite crash (with default compiler options) when trying to execute the module, since module code is loaded above 0x7ffff0000000, while grub-emu-lite code is loaded around 0x400000.

Possible solutions:

0. Add an overflow check to grub_arch_dl_relocate_symbols().
1. Try to allocate module code near core code.
2. Use the system's dlopen() and dlsym() calls for loading modules in grub-emu-lite instead of the built-in loader.
3. Compile with -mcmodel=large, which makes 32-bit relocations disappear.

<qwertial>

 

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 qwertial (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
    Sat 04 May 2013 09:26:49 PM UTCphcoderStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup