[bug #36672] GRUB fails to read FAT filesystem label

[qwertial]

URL:
  <http://savannah.gnu.org/bugs/?36672>

                 Summary: GRUB fails to read FAT filesystem label
                 Project: GNU GRUB
            Submitted by: qwertial
            Submitted on: Sun 17 Jun 2012 08:52:24 AM GMT
                Category: None
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 
                 Release: Bazaar - trunk
         Reproducibility: None
         Planned Release: None

    _______________________________________________________

Details:

Steps to reproduce:
1. Start GRUB on a system with a disk containing a FAT partition with a label.
It may even be QEMU with a VVFAT.
2. ls -l
3. Stare at the machine in confusion as it reboots.

As I investigated, it turned out that the root problem is probably a compiler
bug, so it probably should be sent to the GCC team, but...

When gdb.mod is loaded, GRUB catches exception 0xd (GPF) and prints a stack
trace pointing to the FAT module. From what I have found out, GRUB returns to
an invalid address from iter_hook inside grub_fat_label. While digging through
the assembly, I found that the jump target in the trampoline points to
iter_hook+1 instead of iter_hook. Here is the disassembly for iter_hook:

=> 0x7ffa644 <iter_hook>:       cmpb   $0x8,0xb(%edx)
   0x7ffa648 <iter_hook+4>:     jne    0x7ffa662 <iter_hook+30>
   0x7ffa64a <iter_hook+6>:     push   %esi
   0x7ffa64b <iter_hook+7>:     push   %ebp
   0x7ffa64c <iter_hook+8>:     mov    %esp,%ebp
   0x7ffa64e <iter_hook+10>:    push   %ecx
   0x7ffa64f <iter_hook+11>:    call   0xd120 <grub_strdup>
   0x7ffa654 <iter_hook+16>:    mov    0x4(%ebp),%edx
   0x7ffa657 <iter_hook+19>:    mov    (%edx),%edx
   0x7ffa659 <iter_hook+21>:    mov    %eax,(%edx)
   0x7ffa65b <iter_hook+23>:    mov    $0x1,%eax
   0x7ffa660 <iter_hook+28>:    jmp    0x7ffa665 <iter_hook+33>
   0x7ffa662 <iter_hook+30>:    xor    %eax,%eax
   0x7ffa664 <iter_hook+32>:    ret    
   0x7ffa665 <iter_hook+33>:    leave  
   0x7ffa666 <iter_hook+34>:    pop    %edx
   0x7ffa667 <iter_hook+35>:    ret

Before jumping into iter_hook, the trampoline pushes a pointer to the
enclosing function context, but as we can see from disassembly, iter_hook does
not pop that pointer at all (and it seems to refer to it wrongly). It seems
that this routine is not the only one for which wrong trampoline is generated,
but because most of them start with a one-byte push instruction, the resulting
stack pointer misadjustments cancel out. This one does not, but it
resynchronises with the correct instruction stream quite quickly:

   0x7ffa645 <iter_hook+1>:     jp     0x7ffa652 <iter_hook+14>
   0x7ffa647 <iter_hook+3>:     or     %dh,0x18(%ebp)
   0x7ffa64a <iter_hook+6>:     push   %esi
   0x7ffa64b <iter_hook+7>:     push   %ebp
   0x7ffa64c <iter_hook+8>:     mov    %esp,%ebp

Compiling with gcc version 4.7.0 20120505 (prerelease), on
x86_64-unknown-linux-gnu, targeting i386-pc.

Interestingly, when manually fixing the return address, or when using the
x86_64-efi version, GRUB tells me that "filesystem `fat' does not support
labels"; and the grub-probe tool (on x86_64) prints "(nil)" as the filesystem
label. So the compiler bug may be not the only one here, or at least not just
on i386.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36672>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/