GNU 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: |
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> |
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:
|
Tomasz Kępczyński <tomkep> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Powered by Savane 3.13-02a9.
Corresponding source code
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?