On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko phcoder@gmail.com wrote:
The code itself looks good but I'd like more details. Reading 0xffffffff shouldn't cause reboot. Why does it?
It's probably implementation defined reading a multi-byte object from 4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction never gets terminated?
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" arvidjaar@gmail.com a écrit :
I was debugging problem reported by user on Dell Dimension 8300 - it rebooted when doing "ls -l". It turned out, the problem was triggered by loading cbfs which probed for header. System has 2GB memory, and attempt to read from address 0xffffffff caused instant reboot. 0xffffffff was returned by read from non-existing address 0xfffffffc.
The proof of concept patch below avoids it, but I wonder what the proper fix is.
diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c index a34eb88..a5a2fde 100644 --- a/grub-core/fs/cbfs.c +++ b/grub-core/fs/cbfs.c @@ -344,8 +344,9 @@ init_cbfsdisk (void)
ptr = *(grub_uint32_t *) 0xfffffffc; head = (struct cbfs_header *) (grub_addr_t) ptr;
- grub_dprintf ("cbfs", "head=%p\n", head);
- if (!validate_head (head))
if (0xffffffff - ptr < sizeof (*head) || !validate_head (head)) return;
cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Aaron Durbin