Yesterday I start v3 on qemu. As payload i used etherboot 5.4.3, it worked fine. http://rom-o-matic.net/5.4.3/build.php?version=5.4.3&F=&arch=i386&am...
The only trouble is Lar. There the output: --- domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:00.0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.0(PCI: 00:01.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 1 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: Attempting to open 'normal/payload/segment0'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: CHECK normal/payload/segment0 @ 0xfffe8850 start 0xfffe88a0 len 24320 reallen 24320 compression 0 entry 0x000100b0 loadaddress 0x00010000 LAR: Compression algorithm #0 (none) used LAR: Attempting to open 'normal/payload/segment1'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000100b0 CPU 1338 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org ---
How can i solve this?
Regards Markus
On 20.03.2008 09:03, Bios wrote:
Yesterday I start v3 on qemu. As payload i used etherboot 5.4.3, it worked fine. http://rom-o-matic.net/5.4.3/build.php?version=5.4.3&F=&arch=i386&am...
The only trouble is Lar. There the output:
domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:00.0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.0(PCI: 00:01.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 1 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found!
normal/payload was not found. Expected because normal/payload has been split into segments.
LAR: Attempting to open 'normal/payload/segment0'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: CHECK normal/payload/segment0 @ 0xfffe8850 start 0xfffe88a0 len 24320 reallen 24320 compression 0 entry 0x000100b0 loadaddress 0x00010000 LAR: Compression algorithm #0 (none) used
segment0 loaded successfully.
LAR: Attempting to open 'normal/payload/segment1'. LAR: Start 0xfffe0000 len 0x20000 LAR: seen member normal/option_table LAR: seen member normal/initram/segment0 LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/stage2/segment2 LAR: seen member normal/payload/segment0 LAR: seen member bootblock LAR: File not found! LAR: load_file: No such file 'normal/payload/segment1'
segment1 does not exist. LAR tries to find segment0...segmentN until segmentN doesn't exist.
LAR: load_file_segments: All loaded, entry 0x000100b0
Should be OK.
CPU 1338 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org
How can i solve this?
We may need to improve the error message.
Regards, Carl-Daniel
On Thu, Mar 20, 2008 at 08:03:57AM +0000, Bios wrote:
The only trouble is Lar.
..
LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000100b0 CPU 1338 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org
How can i solve this?
Does Etherboot start? Then you are in good shape.
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think we will fix it but so far I think everything works anyway.
//Peter
On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge peter@stuge.se wrote:
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think we will fix it but so far I think everything works anyway.
I don't quite get counterintuitive but hey ...
security hole? the whole bios is that :-)
ron
On Thu, Mar 20, 2008 at 09:40:11AM -0700, ron minnich wrote:
On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge peter@stuge.se wrote:
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think we will fix it but so far I think everything works anyway.
I don't quite get counterintuitive but hey ...
User stores a payload with n segments into flash, uses a coreboot tool (lar) to do so, and yet information is lost until coreboot run time when the payload is to be executed.
security hole? the whole bios is that :-)
Think flashing over padding files with a rouge segment.
//Peter
ron minnich wrote:
On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge peter@stuge.se wrote:
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think 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.
On 22.03.2008 12:04, Stefan Reinauer wrote:
ron minnich wrote:
On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge peter@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
Am Thu, 20 Mar 2008 17:27:57 +0100 schrieb Peter Stuge peter@stuge.se:
On Thu, Mar 20, 2008 at 08:03:57AM +0000, Bios wrote:
The only trouble is Lar.
..
LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000100b0 CPU 1338 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org
How can i solve this?
Does Etherboot start? Then you are in good shape.
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think we will fix it but so far I think everything works anyway.
//Peter
Yes Etherboot starts and lunch the elf-Image of my kernel. For me it was the moste pain until i know that etherboot need an elf version of vmlinuz + initrd
Am Thu, 20 Mar 2008 17:27:57 +0100 schrieb Peter Stuge peter@stuge.se:
On Thu, Mar 20, 2008 at 08:03:57AM +0000, Bios wrote:
The only trouble is Lar.
..
LAR: load_file: No such file 'normal/payload/segment1' LAR: load_file_segments: All loaded, entry 0x000100b0 CPU 1338 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org
How can i solve this?
Does Etherboot start? Then you are in good shape.
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think we will fix it but so far I think everything works anyway.
//Peter
Yes Etherboot starts and lunch the elf-Image of my kernel. For me it was the moste pain until i know that etherboot need an elf version of vmlinuz + initrd
-
Bios -
Carl-Daniel Hailfinger -
Markus
-
Peter Stuge -
ron minnich -
Stefan Reinauer