[coreboot] Time for a new project

[Stefan Reinauer]

Am 12.04.2008 um 07:52 schrieb Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net 
 >:

> On 12.04.2008 15:55, Patrick Georgi wrote:
>> Am Samstag, den 12.04.2008, 13:16 +0200 schrieb Carl-Daniel  
>> Hailfinger:
>>
>>> SELF is missing a checksum for each uncompressed segment.
>>>
>> It has a checksum for the whole file (in LAR), isn't that enough?
>>
>
> That depends on whether you want to catch corruption during  
> decompression.
>

This is bogus, sorry.

>>> SELF is missing a per-section compression algorithm specifier and  
>>> if you
>>> introduce one, you have a compression algorithm specifier both in  
>>> LAR
>>> and in SELF. If you remove it from LAR, you have no way to store
>>>
>> BSS is defined to be the implicit-RLE-0 compressor. Everything else
>> probably defaults to a single one (LZMA).
>>
>
> I don't know whether we really want to make building an uncompressed
> image impossible.

No, instead we make this stuff well defined.

>
>
>>> Sorry, you misunderstood. The obvious speed penalty comes from  
>>> unaligned
>>> accesses. Some architectures can't even handle unaligned accesses  
>>> at all.
>>>
>> Uhm, once the LAR header is aligned (it is), and of a size multiple  
>> the
>> alignment size, the data is aligned, too - right?
>>
>
> The LAR header is aligned, the SELF headers are aligned as well, but  
> the
> individual SELF chunks containing LZMA headers are not.
>

Wrong. Besides at least nrv2b is byte streaming.


>>> So you propose to handle some executable code (bootblock, raminit)  
>>> just
>>> with LAR and not with SELF? How are you going to explain that  
>>> concept a
>>> few years down the road?
>>>
>> That code doesn't need a BSS section, in case of the bootblock it
>> doesn't even need an entry point (as far as I can see). So we  
>> actually
>> have two classes of code here:
>> - initialization
>> - upper level
>>
>> So yes, just adding the pre-stage6 stuff as simple binary seems  
>> totally
>> obvious to me, if stage6 is the first one to carry a SELF parser.
>>
>
> Sorry, what is stage 6?
>
>
>>> Wrong. Checksums say nothing about corrupt internal SELF  
>>> structure. The
>>> LAR parser has the ability (well, at least in theory) to check for
>>> overlapping archive members right now. With SELF, a corrupt SELF  
>>> header
>>> can reference arbitrary places in the archive and a pure LAR parser
>>> can't find that out because it does not parse SELF by design.
>>>
>> What kind of corruption do you refer to?
>> The one that happens before the file it put in the LAR? (so the LAR
>> checksum matches) There shouldn't be any, if the SELF creator works
>> right.
>>
>
> If the SELF creator works right. Exactly. If it produces random  
> garbage,
> LAR has no way to know.

That's a bogus reason. The current code could just as easily produce  
garbage and checksum it right. Making per segment checksums does not  
improve the situation at all.

>
>
>> The one that happens later should be caught by LAR's checksum.
>>
>> And just like the SELF creator, the LAR creator could have a bug and
>> create broken structures.
>>
>
> Indeed. However, right now a LAR verifier could find all broken
> structures. With the new design, we would need a LAR+SELF verifier.

Not at all. LAR takes care of the integrity. That's what i designed it  
to do.


>
>
>>> And since a pure LAR parser does not understand SELF, you need a
>>> combined SELF+LAR parser to know whether the ROM has a chance to  
>>> boot.
>>>
>> Does your parser also check if the bootblock starts with RET? Or  
>> solve
>> the halting problem?
>>
>
> No, but it can make sure that accessing any LAR member will not try to
> reference memory outside the LAR member. Accessing a SELF chunk can
> easily reference memory outside the LAR member and even outside the  
> archive.

No because that would mean the file is corrupt and the lar checksum  
would catch that.

>
>
>>> The bootblock and initram are executable files. They should be  
>>> contained
>>> in SELF as well (and that means you should be able to state that the
>>> code is XIP). Tables which should be loaded to a given address in  
>>> memory
>>>
>> the bootblock isn't loaded by a SELF parser - even if it gets a  
>> suitable
>> header, it would implicitely be XIP.
>>
>
> OK, agreed for the bootblock. But how do you mark initram XIP?
>

Initram is not segments now either.you know its xip. To lar its just a  
hunk of data