Sure, that works.

Le dim. 14 févr. 2016 03:45, Eric Snowberg <eric.snowb...@oracle.com> a
écrit :

>
> > On Feb 13, 2016, at 9:08 AM, Eric Snowberg <eric.snowb...@oracle.com>
> wrote:
> >
> >>
> >> On Feb 13, 2016, at 7:05 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> >>
> >>
> >>
> >> Le sam. 13 févr. 2016 01:51, Eric Snowberg <eric.snowb...@oracle.com>
> a écrit :
> >> Prevent buffer over-read in grub_machine_mmap_iterate. This was
> >> causing phys_base from being calculated properly. This then
> >> caused the wrong value to be placed in ramdisk_image within
> >> struct linux_hdrs. Which prevented the ramdisk from loading on
> >> boot.
> >>
> >> Newer SPARC systems contain more than 8 available memory entries.
> >>
> >> For example on a T5-8 with 2TB of memory, the memory layout could
> >> look like this:
> >>
> >> T5-8 Memory
> >> reg                      00000000 30000000 0000003f b0000000
> >>                         00000800 00000000 00000040 00000000
> >>                         00001000 00000000 00000040 00000000
> >>                         00001800 00000000 00000040 00000000
> >>                         00002000 00000000 00000040 00000000
> >>                         00002800 00000000 00000040 00000000
> >>                         00003000 00000000 00000040 00000000
> >>                         00003800 00000000 00000040 00000000
> >> available                00003800 00000000 0000003f ffcae000
> >>                         00003000 00000000 00000040 00000000
> >>                         00002800 00000000 00000040 00000000
> >>                         00002000 00000000 00000040 00000000
> >>                         00001800 00000000 00000040 00000000
> >>                         00001000 00000000 00000040 00000000
> >>                         00000800 00000000 00000040 00000000
> >>                         00000000 70000000 0000003f 70000000
> >>                         00000000 6eef8000 00000000 00002000
> >>                         00000000 30400000 00000000 3eaf6000
> >> name                     memory
> >>
> >> Signed-off-by: Eric Snowberg <eric.snowb...@oracle.com>
> >> ---
> >> grub-core/kern/ieee1275/mmap.c |    5 ++++-
> >> 1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/grub-core/kern/ieee1275/mmap.c
> b/grub-core/kern/ieee1275/mmap.c
> >> index 911bb00..8df4e9b 100644
> >> --- a/grub-core/kern/ieee1275/mmap.c
> >> +++ b/grub-core/kern/ieee1275/mmap.c
> >> @@ -25,7 +25,7 @@ grub_machine_mmap_iterate (grub_memory_hook_t hook,
> void *hook_data)
> >> {
> >>   grub_ieee1275_phandle_t root;
> >>   grub_ieee1275_phandle_t memory;
> >> -  grub_uint32_t available[32];
> >> +  grub_uint32_t available[64];
> >> Please 512 at least so this can lands further down the road
> >
> > Ok, I’ll change the array to 512
>
> I tested this new patch out with 512, it doesn’t work well with some older
> OBP versions.  I get an error from OBP that I’ve never seen before.  I
> changed it to 128 and this seems to work.
>
> Would you accept 128 instead?  If so, I need to test it on some more
> equipment before sending out the updated patch.
>
> >
> >>   grub_ssize_t available_size;
> >>   grub_uint32_t address_cells = 1;
> >>   grub_uint32_t size_cells = 1;
> >> @@ -49,6 +49,9 @@ grub_machine_mmap_iterate (grub_memory_hook_t hook,
> void *hook_data)
> >>                                          sizeof available,
> &available_size))
> >>     return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
> >>                       "couldn't examine /memory/available property");
> >> +  if (available_size > sizeof available)
> >> Brackets around available
> >> +    return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
> >> +                       "/memory response buffer exceeded”);
> >
> > And I’ll add the brackets and resubmit
> >
> >>
> >>   if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_BROKEN_ADDRESS_CELLS))
> >>     {
> >> --
> >> 1.7.1
> >>
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to