[LinuxBIOS] [PATCH][LAR] New LAR access functions

Peter Stuge peter at stuge.se
Thu Jul 12 18:37:27 CEST 2007


On Thu, Jul 12, 2007 at 04:49:35PM +0200, Stefan Reinauer wrote:
> > > +	unsigned int *ptr = (unsigned int *) (lar->map + (filelen - 12));
> > 
> > What about all this pointer arithmetic? Is it really correct?
>  
> This code is not new, it is in another file already.

Yes. Sorry. It's fine.


> > Doesn't adding 1 to a pointer actually add sizeof pointed-to-type
> > to the address? Ie. this code isn't portable?
> 
> What makes you think so? It fetches an int from 12 bytes before the
> end of the file (ie. after the reset vector). 

I did not pay attention to the type of lar->map.


> It is of course not portable because there is no reset vector
> at fffffff0 on non x86 machines. But that's another issue.

..

> > but then writing size to p[0] will write a different number of
> > bytes on different archs, right?
> 
> int is 32bit on all GNU architectures I know that could
> theoretically run LinuxBIOS.

My point is that this is lar and not LB. While LB is completely tied
to the architecture we want lar to be the opposite. I expect lar and
larballs to be platform independent, just like other archivers and
good file systems. :)


> But since this is an x86 only thing anyways I would not care too
> much.

lar shouldn't be an x86 only thing, should it?


> > > +	lar =  _open_lar(archive, s.st_size, O_RDWR);
> > 
> > Race conditions. First open() then fstat() to get the size.
>  
> What kind of situation that realisticly happens would produce such
> an issue? i.e. While a payload builds a lar, or while LinuxBIOS is
> compiled?

Interactive buildrom and automated v3 abuild running at the same
time e.g. (In the same place.)

Yes, it's rather theoretical and there's no point in jumping through
hoops trying to recover from it - I'm requesting a way to measure
that the larball was broken by someone else and that lar doesn't
create a crazy big file.


//Peter




More information about the coreboot mailing list