[coreboot] Time for a new project

[Stefan Reinauer]

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

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

You want to catch compiler bugs during runtime? Come on let's get  
serious again and deal with the real world.


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

Right. Using the lar specified compression algorithm.
So?

Keep in mind that we handle segments much differently than xip and  
blobs already.

>
>
>> Again, LAR does the work. No?
>>
>
> See above. I wouldn't have complained that much if you were right.
>

Ehem

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

At some point the entry point to a blob was at the beginning of the  
file. Adding the flexibility to begin with moved complexity from  
compile time to run time -- guess what, that was a bad idea.

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


What problem are you trying to catch?right now this is just artificial
>
>
>>>>> 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.

in the real world this is not true.


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

Beause of what?compiler bugs? In that case the miscompiled panic room  
will not help us.

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

Wrong and right.

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

They are handled already


>>> 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
>
> -- 
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>