[coreboot] Time for a new project

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Apr 12 22:59:54 CEST 2008


@Peter: One apology for you near 2/3 of the mail.
@Segher: One gcc question for you near the end of the mail.

On 12.04.2008 21:07, Stefan Reinauer wrote:
> Am 12.04.2008 um 08:06 schrieb 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
>
> You want to catch compiler bugs during runtime? Come on let's get  
> serious again and deal with the real world.
>   

Some Linux kernel verification mechanisms have caught compiler bugs in
the past. That's why I considered the possibility to do this as well.

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

Layering violation, but doable.

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

OK.

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




@Peter: Sorry, this came across in a way that was unintended. Let me try
to rephrase:
I would not have complained if the SELF wiki page had agreed with Peter
(because I agree with many of his points). However, I understood the
wiki page as reference spec and that meant Peter was conflicting
("wrong") with it. I prefer Peter's and Stefan's opinion over the "spec"
in the wiki page any time and hope both of them will edit the wiki page
to match their ideas about SELF.





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

Unless you fork gcc, having the entry point at the beginning of initram
is not possible. It worked by accident in the past and I'm pretty sure
Segher will confirm that we can't rely on that.

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

The extract SELF from LAR, corrupt SELF, add SELF to another LAR
scenario from my other mail (~10 minutes ago).

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

What's not true in the real world? Will LAR have knowledge of SELF and
parse/check/verify/etc it?

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

Because of the scenario above.

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

For the initram entry point discussion see my response above.

>  and right.
>   

That means we have to store the entry point for initram somewhere.

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

As SELF or as simple LAR member?


Regards,
Carl-Daniel




More information about the coreboot mailing list