[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

On 12.04.2008 16:14, Peter Stuge wrote:
> On Sat, Apr 12, 2008 at 01:16:00PM +0200, Carl-Daniel Hailfinger wrote:
>   
>> On 12.04.2008 10:28, Stefan Reinauer wrote:
>>     
>>> Carl-Daniel Hailfinger wrote:
>>>       
>>>> NAK. This design is so unfinished it is not even funny. Hint: Certain
>>>> fields in the LAR header are there for a reason (guess which).
>>>>         
>>> Yes, and because that concept is so incredibly broken beyond belief,
>>> we fixed it up at the summit. Those completely archive-unrelated
>>> fields which just sneaked into lar because we did not do our reviews
>>> thoroughly enough will finally go away again. Way to go.
>>>       
>> SELF is missing a checksum for each uncompressed segment.
>>     
>
> Is that really needed? That means we expect the decompression to
> fail silently.
>   

That could happen.

> If LAR provides a reliable transport then why add another checksum?
>   

Memory corruption during decompression and miscompilation of the
decompression code come to mind.

>> SELF is missing a per-section compression algorithm specifier
>>     
>
> Does it need one? Either the entire SELF is compressed, or not.
>   

Uh, no. The SELF design says that only some SELF segments may be
compressed, others must not be compressed.

> Again, LAR does the work. No?
>   

See above. I wouldn't have complained that much if you were right.

>> Sorry, you misunderstood. The obvious speed penalty comes from
>> unaligned accesses. Some architectures can't even handle unaligned
>> accesses at all.
>>     
>
> Can't this be solved generically in code like in memcpy_helper() ?
>   

Are you willing to copy the lzma header for every lzma-compressed SELF
segment to some reserved place in RAM? Are you willing to rewrite the
decompression code so that it can handle a detached lzma header?

>>>> The concept of PIC is missing completely.
>>>>         
>>> Because it is not needed.
>>>       
>> 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?
>>     
>
> KISS. Since the early LAR files are simple binaries they don't need
> to be SELF.
>   

raminit needs an entry point, so it has to be SELF (unless you propose
that LAR and SELF both specify an entry point).

>>>> A LAR parser can't figure out if the archive is corrupt.
>>>>         
>>> Plain wrong. There's checksums in the lar, and that wont change.
>>>       
>> 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
>>     
>
> First of all, how would it end up corrupt? It must then be corrupt
> upon SELF creation, because if it changed in LAR, the LAR checksum
> would not match anymore.
>   

See my other mail in response to Patrick.

>> 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.
>>     
>
> Why does this matter, in practise? More than one SELF will never be
> up in the air. And so what if it references locations in the LAR?
>   

A LAR archive can have multiple SELFs and each of them can reference
arbitrary memory and the LAR parser has no way to check that. A SELF
parser could check that, but then it would have to know about the LAR
structure which is a layering violation.

>>>> Ron once stated the ability to figure out whether the ROM is
>>>> corrupt before you flash it is one of the key features of LAR.
>>>>         
>> 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.
>>     
>
> What would be checked in the SELF? Isn't it good enough that there is
> a SELF with the right name?
>   

Currently, the ELF-to-LAR parser has a reasonable chance to find out
whether the structure of the ELF is crap. If LAR simply handles a SELF
as opaque object, it will not notice at all if the SELF is crap.

> I think it is impossible to reliably determine boot success ahead of
> time. Only trying to boot will show the actual outcome, especially
> since we want to reflash individual LAR files. I guess I disagree
> with Ron's statement. LAR is very nice, but it can't predict the
> future. :)
>   

What? And I trusted its baseball result predictions for 2009 ;-)

> Instead the coreboot panic room will be the key feature in this
> domain. The fact that you don't just get beeps from a speaker but
> an actual way into your system regardless.
>   

Are we guaranteed to reach the panic room if the SELF points to
arbitrary memory?

>>> LAR is an archiver of arbitrary(!) files, SELF is the container
>>> for executable files. Mixing these two up was the biggest mistake
>>> in the history of the young LAR, making things irreversible and
>>> fragile.
>>>       
>
> Word.
>
>   
>> The bootblock and initram are executable files. They should be
>> contained in SELF as well
>>     
>
> I don't think that is neccessary.
>   

initram needs an entry point. Storing an entry point in LAR and in SELF
is really bad design.

>> Tables which should be loaded to a given address in memory are by
>> definition NOT code, yet you have to supply a load address
>>     
>
> Hm, what kind of tables? What would this be that is just copied from
> LAR using some generic code rather than code that knows about the
> neccessary adress already?
>   

Hm. I know of no such table yet. What about option ROMs?

>> Unfortunately, the current SELF+LAR proposal is not able to keep
>> the design simple and still perform all tasks we currently use LAR
>> for.
>>     
>
> This is where I'm lost. Please explain what would not work anymore?
>   

I hope I listed most of my concerns above.

Regards,
Carl-Daniel