[coreboot] Multiboot

Robert Millan rmh at aybabtu.com
Tue Sep 23 15:19:31 CEST 2008


On Tue, Sep 23, 2008 at 10:10:31AM +0200, Mathias Krause wrote:
> Hi,
> 
> Robert Millan wrote:
> >   - Add "edx" to clobber list.  Together with eax and ecx which are already
> >     in input list, this makes the call able to return for any payload that
> >     complies with "cdecl" calling convention.
> 
> ...
> 
> > +
> > +static int run_address_multiboot(void *f)
> > +{
> > +	int ret;
> > +	__asm__ __volatile__ ("call *%3" : "=a" (ret) : "a" (MB_MAGIC2), "b" (0xf0000), "c" (f) : "edx");
> > +	return ret;
> > +}
> > +
> 
> this assembler inline is not quite correct to be able to let the call
> return because the compiler assumes that after this assembler statement
> %ecx still holds the value f which hasn't to be the case. It assumes the
> same for %ebx but this should be no problem since the calling function
> must preserve it's value if it follows the C calling convention. But
> %ecx isn't one of the registers that needs to be preserved, so the
> assumption the compiler makes here is wrong.
> 
> How about this one:
> 
> | static int run_address_multiboot(void *f)
> | {
> |     int ret, dummy;
> |     __asm__ __volatile__ ("call *%4" : "=a" (ret), "=c" (dummy) : "a"
> (MB_MAGIC2), "b" (0xf0000), "c" (f) : "edx", "memory");
> |     return ret;
> | }

I see.  But why not just add "ecx" to clobber list instead?  Then a dummy
variable isn't needed.

> The memory clobber is needed since you cannot know what the called
> function will actually do with the memory and to ensure all cached
> values are actually written back to memory before calling f().

Is this really a problem?  If the payload expects to return, it isn't
supposed to modify coreboot's memory at all.  If it does, I'd say it's
normal that things break.

-- 
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."




More information about the coreboot mailing list