[coreboot] Time for a new project
stepan at coresystems.de
Sat Apr 12 20:44:37 CEST 2008
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
>>> 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
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
>>> 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
>>> 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
>> alignment size, the data is aligned, too - right?
> The LAR header is aligned, the SELF headers are aligned as well, but
> 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)
>>> 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
>> have two classes of code here:
>> - initialization
>> - upper level
>> So yes, just adding the pre-stage6 stuff as simple binary seems
>> 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
>>> 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
> If the SELF creator works right. Exactly. If it produces random
> 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
>>> 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
>> Does your parser also check if the bootblock starts with RET? Or
>> 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
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
>>> 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
>> the bootblock isn't loaded by a SELF parser - even if it gets a
>> 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
More information about the coreboot