[coreboot] Time for a new project
c-d.hailfinger.devel.2006 at gmx.net
Sat Apr 12 16:52:49 CEST 2008
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.
>> 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
>> 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.
>> 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
If the SELF creator works right. Exactly. If it produces random garbage,
LAR has no way to know.
> 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.
>> 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.
>> 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?
More information about the coreboot