@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];
EVP_Digest(header,length,md,NULL,EVP_sha256(),NULL);
//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 header_size) {
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/home/sphinx/coreboot/coreboot_o/coreboot-v2/src/include -I/home/sphinx/coreboot/coreboot_o/coreboot-v2/src/arch/i386/include -I/usr/lib/gcc/i486-linux-gnu/4.3.2/include -include /home/sphinx/coreboot/coreboot_o/coreboot-v2/targets/emulation/qemu-x86/qemu-x86/normal/settings.h -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 /usr/local/ssl/lib/libcrypto.a /home/sphinx/coreboot/coreboot_o/coreboot-v2//src/boot/elfboot.c
all: coreboot.rom coreboot_ram.o: src/arch/$(ARCH)/lib/c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME) $(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 /home/sphinx/coreboot/coreboot_o/coreboot-v2/src/config/coreboot_ram.ld /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.
Regards,
René
2009/7/28 René Reuter reuter.rene@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@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:
- wrong library path
- wrong library type (dynamic instead of static)
- 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