[coreboot] coreboot V2 with crypto library

René Reuter reuter.rene at googlemail.com
Tue Jul 28 13:34:31 CEST 2009

@Carl: OK here are the changes I've made:

file: src/boot/elfboot.c

+ #include <openssl/sha.h>
+ #include <openssl/evp.h>

+ #define SHA256_DIGEST_LENGTH    32

+ static void measure_elf(unsigned char *header, size_t length) {
        unsigned char md[SHA256_DIGEST_LENGTH];


         //write_log_entry_in_tcpa(hash); // Write hash to the acpi table

         measure_and_extend(md); //Write hash to the tpm
         return 1;

 * Dummy function for tpm capability
+ static int measure_and_extend(unsigned char hash) {
        return 1;

static int load_elf_segments(
        struct segment *head, unsigned char *header, unsigned long

                        memcpy(dest, &header[start_offset], len);
                     + measure_elf(&header[start_offset], len); //Pass the
elf code to the measurement function


file target/emulation/qemu-x86/qemu-x86/normal/Makfile:

src/boot/elfboot.o: $(TOP)//src/boot/elfboot.c
        gcc -m32 -c  -fno-stack-protector
-I/usr/lib/gcc/i486-linux-gnu/4.3.2/include -include
-O2 -g -nostdlib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common
-ffreestanding -fno-builtin -fomit-frame-pointer -I /usr/local/ssl/include
-lcrypto -lssl -Wall -o src/boot/elfboot.o /usr/local/ssl/lib/libssl.a

all: coreboot.rom
coreboot_ram.o: src/arch/$(ARCH)/lib/c_start.o $(DRIVER) coreboot.a
        $(CC) $(DISTRO_LFLAGS) -nostdlib -I /usr/local/ssl/include -lcrypto
-lssl -r -o $@ /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a $^
coreboot_ram: coreboot_ram.o $(TOP)/src/config/coreboot_ram.ld ldoptions
        gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -I
/usr/local/ssl/include -lcrypto -lssl -static -o coreboot_ram -T
/usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a coreboot_ram.o

As I've said in IRC don't wonder, cause of the direct gcc calls, I just need
to get it running and tried out a lot of stuff.



2009/7/28 René Reuter <reuter.rene at googlemail.com>

> Ok first two commands I get the same output like you.
> The third:
> gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -L/usr/lib/
> -lcrypto -lssl -static -print-file-name=libcrypto.a
> /usr/bin/ld: no input files
> collect2: ld returned 1 exit status
> The objdump returns elf32-i386 for all
> René
> 2009/7/28 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>> On 28.07.2009 12:05, René Reuter wrote:
>> > I've changed that path already, tried every possibility. I even asked
>> the
>> > gcc guys if they now any possibility how i could provide the lib, but it
>> > always crashes.
>> >
>> (Any commands you have to run are preceded by a #)
>> It doesn't crash, it just throws an undefined reference error. Looking
>> at the undefined reference error, it complains EVP_sha256 is missing.
>> Next question is why that symbol is missing although you had -lcrypto in
>> the command line. Run the following command:
>> # grep -l EVP_sha256 /usr/lib/libcrypto*
>> Expected output is:
>> /usr/lib/libcrypto.a
>> /usr/lib/libcrypto.so
>> /usr/lib/libcrypto.so.0.9.8
>> If /usr/lib/libcrypto.a is missing, it can't work (unless you're on
>> Debian/Ubuntu with that strange lib layout, and if that is the case,
>> please complain). Now run
>> # objdump -a /usr/lib/libcrypto.a|grep format
>> Expected output is:
>> cryptlib.o:     file format elf32-i386
>> mem.o:     file format elf32-i386
>> mem_clr.o:     file format elf32-i386
>> mem_dbg.o:     file format elf32-i386
>> cversion.o:     file format elf32-i386
>> ex_data.o:     file format elf32-i386
>> [...]
>> If the output differs (maybe showing "file format elf64-x86-64"), it
>> can't work. Now run
>> #gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -L/usr/lib/
>> -lcrypto -lssl -static -print-file-name=libcrypto.a
>> Expected output is:
>> /usr/lib/gcc/i586-suse-linux/4.2.1/../../../libcrypto.a
>> Run the objdump command from above for the file listed in the gcc
>> output. If the file format is not elf32-i386, it can't work.
>> And now the prize question: How did I arrive at the diagnosis above:
>> Simple. If the linker can't find some symbols, it means the required
>> library is not where gcc expects it. Three possible reasons for that:
>> 1. wrong library path
>> 2. wrong library type (dynamic instead of static)
>> 3. wrong architecture (x86_64 instead of i386)
>> Next, I opened the man page for gcc and searched for nostdlib. First hit
>> explains how to print the file name for any library you want gcc to use.
>> If that library does not match what gcc needs for linking your specific
>> project, gcc will  complain during linking.
>> Regards,
>> Carl-Daniel
>> --
>> http://www.hailfinger.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090728/f53972d6/attachment.html>

More information about the coreboot mailing list