[coreboot] qemu v3 etherboot

[Carl-Daniel Hailfinger]

On 22.03.2008 12:04, Stefan Reinauer wrote:
> ron minnich wrote:
>   
>> On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge <peter at stuge.se> wrote:
>>   
>>     
>>>  Currently v3 looks for segments until a segment cannot be found.
>>>
>>>  This is counterintuitive and potentially a security hole, I think
>>>       

The potential security hole would be scribbling over unlocked flash
space with a rogue segment which takes control. Please be aware that
this attack is negligible right now because of another easier attack
which will NOT be fixed by any suggested format change:
Right now, any standard x86 boot with non-working NVRAM (or fallback
flag in NVRAM) tries to run fallback/initram first, but any standard x86
build only provides normal/initram. That means if the attacker can add
fallback/initram somewhere in flash, he has succeeded. Unless we manage
to "fix" that (and it is really debatable whether we can actually lock
out flash writes by software with any desktop mainboard (maybe except
for some SMM trickery)), the whole issue is moot. Right now, at least
the failure modes are very well understood. Once we make this
half-secure, some security researcher is going to point out we failed to
make it completely secure. Simply declare the whole issue as to-be-done
or unfixable and kill any motivation of security researchers to point
out the flaws because they are already documented.

>>>  we will fix it but so far I think everything works anyway.    
>>>       
>
> Yes, an ELF binary in the filesystem should not become many binaries in
> the LAR file. We should take that pseudo-simple-elf-segment-only file
> format out of the LAR format itself. It has nothing to do with the
> original purpose of LAR.
>   

I really had trouble understanding what you meant with
"pseudo-simple-elf-segment-only file". AFAICS it about representing each
parsed ELF segment as a separate file. The only proposed format change I
have seen so far would have introduced additional code complexity for
handling not-really-a-file segments in the LAR without removing any code
from the main LAR walking loop.

I'm open to add another field to the header which specifies the number
of segments as that would keep added complexity fairly low and increase
speed at the same time, but other changes would really need to be well
justified.


Regards,
Carl-Daniel