Le 3 nov. 2015 6:46 PM, "Aaron Durbin" adurbin@google.com a écrit :
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?
It would be interesting to find out. Since it's P4, it may be related to PAE but paging is disabled when GRUB is active However it shouldn't hold this patch. Andrei: go ahead, just please add reference to machine and cpu in the comment and the fact that we have little idea what's going on.
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
-
Vladimir 'phcoder' Serbinenko