bugGNU GRUB - Bugs: bug #50715, GRUB stack overwriting PXE stack...

 
 

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

bug #50715: GRUB stack overwriting PXE stack (or the other way around)

Submitter:  Tomasz Kępczyński <tomkep>
Submitted:  Tue 04 Apr 2017 11:39:59 AM UTC
   
 
Category:  Network Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  2.02~rc1
Release:  Reproducibility:  Every Time
Planned Release:  None

Tue 11 Apr 2017 06:34:39 AM UTC, comment #2: 

Well, the stack location is highly error prone from every view point you look at it... Some hints and remarks you may want to consider:
1. PXE option rom allocates its own 2KB stack with which it call network bootstrap program (grub in this case). You may save SS:[E]SP somewhere and use this stack when doing real mode calls. SS should point to the segment pointed by word 0x40:0x13 (multiplied by 64 to convert it from kB units to paragraphs) and SP starts with stack size and when it reaches 0 you've exhausted it.
2. As for using stack at the top of conventional memory, this is hard to get it right. I've seen platforms where EBDA was 80kB large BEFORE iSCSI option rom loaded adding additional 25kB on top of it. Theoretically it should have refused loading (PCI firmware specification 3.0 limits permanent memory usage below 1MB to 40kB total, shared between all option roms), but try to explain that to customers. Having 80kB EBDA and 86-88kB PXE places grub stack around 472-474kB.
3. I personally think stack should go just below bootstrap code at 0:0x7C00, as any loaded program goes there and stack below it should be safe.

One more remark: isn't it possible to hardcode protstack for the code running before the memory management code has executed but adjust it right after? If this stack is only used for calls made in real mode it probably shouldn't be a problem, should it?

Tomasz Kępczyński <tomkep>
Thu 06 Apr 2017 04:57:23 PM UTC, comment #1: 

Well, this code is run as the very first thing, before any memory allocator is active. I guess we could use different, more "safe" stack location until memory size is detected. But that also means we must restrict max image size, so we still need to have some safe limit statically. In which case we can simply move stack lower.

Andrei Borzenkov <arvidjaar>
Group Member
Tue 04 Apr 2017 11:39:59 AM UTC, original submission:  

Grub is used fixed memory location in the first 640kB (real memory) for its stack when calling real mode services (like PXE, iterrupts and so on). The code leadng to this conclusion is:

grub-core/kern/i386/realmode.S:

protstack:
        .long   GRUB_MEMORY_MACHINE_PROT_STACK
:
protcseg:
:

        /* get protected mode stack */
        movl<-->protstack, %eax
        movl<-->%eax, %esp
        movl<-->%eax, %ebp

where GRUB_MEMORY_MACHINE_PROT_STACK evaluates to 0x7FFF0 from the constants given in include/grub/i386/memory_raw.h file.

Please note that this location IS NOT SAFE to use in certain configurations which use large then usual areas in EBDA and which also use PXE. The first is common for either some iSCSI boot configurations or for some RAID controllers where EBDA usage jumps to 40-50kB. PXE alone will additionally require 86kB (1G Intel PXE version 1.5.84) and it WILL LOCATE ITSELF right below the EBDA. Given the fact that PXE allocates its stack at the bottom of its memory, it can happen that PXE stack and grub stack will at some point try to occupy the same memory location.

Grub CANNOT make assumptions like that about memory areas. It has to check E820 memory map for the safe address space to use for its stack location and it has additionally to take into account any software (like PXE) which only modifies 'available base memory' location at 0x40:0x13 in BDA to hide its memory from other programs.

Tomasz Kępczyński <tomkep>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arvidjaar (Posted a comment)
  • -email is unavailable- added by tomkep (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code