[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

Hi Stefan,

since you seem to disagree violently with my conclusions although most
of my conclusions are supported by the SELF wiki page, the only
explanation is that you disagree with the SELF wiki page as well.

On 12.04.2008 20:44, Stefan Reinauer wrote:
>
> 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 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.

Let me quote the current SELF wiki page: "CODE and DATA sections _may_
be compressed". Without a way to find out whether these sections are
compressed, compression is totally undefined. Feel free to edit the wiki
page to make this 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.

Let me quote the current wiki page again: "The data section immediately
follows the final entry in the segment table. Each block of segment data
is written sequentially in this section." There is no mentioning of any
alignment of the LZMA header at all and the "written sequentially"
suggests there are no gaps. Please correct the wiki page if you disagree
with it.

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

My point here was not about checksums. LAR currently treats ELF files as
binary blobs if you don't preparse them. AFAICS Ron wanted the
preparsing as sort of a security mechanism to determine whether the ELF
looks like a real ELF file. If SELF is treated as a blob by LAR we lose
that advantage.

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

Does it take care of the integrity of each SELF file as well?

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

Scenario: You unpack a LAR. The extracted SELF file becomes corrupted
somehow. You pack it into another LAR. That LAR now has a corrupt SELF
file and you won't notice this during LAR creation.

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

OK.

Regards,
Carl-Daniel