GNU GRUB - Bugs: bug #55849, GRUB2 wrongly uses EBDA
You are not allowed to post comments on this tracker with your current authentication level.
bug #55849: GRUB2 wrongly uses EBDA
Submitter: | Chu-Hsuan <chuhsuan> | ||
Submitted: | Thu 07 Mar 2019 09:48:22 AM UTC | ||
Category: | Booting | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Software Error |
Status: | None | Privacy: | Public |
Assigned to: | None | Originator Name: | |
Open/Closed: | Open | Release: | 2.02 |
Release: | Reproducibility: | Every Time | |
Planned Release: | None |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
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
Powered by Savane 3.13-758e.
Corresponding source code
In grub_acpi_create_ebda() in grub-core/commands/acpi.c, it wrongly use EBDA with hard code.
1. It should not copy only first 0x400 bytes to new EBDA. The total size should be copied to new EBDA is based on original size. If original EBDA size is 0x2 (the first word of EBDA), it means it should copy 2*0x400 bytes to new EBDA.
2. It should not hard code to add "1" to new EBDA size. It should calculate based on how much size it created. For example, original EBDA is 9f80:0 and size is 0x2 (unit is 1K) and new EBDA is 9e80:0. Because 9f80:0 - 9e80:0 is 4K, the new EBDA size should be 0x2+0x4 = 0x6.
3. Keep original data at the same offset and use higher memory partion. For example, original EBDA is 9f80:0 and size is 0x2 and new EBDA is 9e80:0. In this case, it should copy data from 9f80:0 ~ 9fff:f to 9e80:0 ~ 9eff:f and new 9f00:0 to 9fff:f is available for GRUB2.
I know there is a "--no-ebda" option, but it should not wrongly use EBDA since it decide to use it.