Re: ELF bugfixes

[Robert Millan]

On Sat, Mar 21, 2009 at 07:05:23PM +0100, phcoder wrote:
> Robert Millan wrote:
>> On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote:
>>> Robert Millan wrote:
>>>> On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote:
>>>>> Robert Millan wrote:
>>>>>> On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote:
>>>>>>> -  grub_multiboot_payload_entry_offset = ehdr->e_entry - 
>>>>>>> phdr(lowest_segment)->p_vaddr;
>>>>>>> +  for (i = 0; i < ehdr->e_phnum; i++)
>>>>>>> +    if (phdr(i)->p_vaddr <= ehdr->e_entry +    && 
>>>>>>> phdr(i)->p_vaddr + phdr(i)->p_memsz > ehdr->e_entry)
>>>>>>> +      grub_multiboot_payload_entry_offset = (ehdr->e_entry - 
>>>>>>> phdr(i)->p_vaddr)
>>>>>>> +       + (phdr(i)->p_paddr  - phdr(lowest_segment)->p_paddr);
>>>>>> You need to handle the case in which grub_multiboot_payload_entry_offset 
>>>>>> is left
>>>>>> uninitialized (it needs to be initialized each time the multiboot 
>>>>>> command is
>>>>>> run, not just when the module is loaded).
>>>>>>
>>>>> module? actually it's when loading image. Perhaps you mean that   
>>>>> additional error check is necessary
>>>> I meant GRUB's multiboot.mod, not the payload's module.  Sorry I wasn't 
>>>> clear.
>>>>
>>> With this error check if grub_multiboot_payload_entry_offset it can   
>>> happen only if no image is loaded. And actually   
>>> grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load
>>> So I don't really understand the problem
>>
>> You can't rely on grub_multiboot_payload_entry_offset being set to 0, because
>> any subsequent call of "multiboot /something" has the potential to override
>> this.  You must not assume the multiboot command is only going to be run 
>> once.
>>
> No but it always corresponds to the current image. It's set either in  
> multiboot.c or in grub_multiboot_load_elf

It is now, but your code makes this conditional.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."