coreboot V2 with crypto library

[René Reuter]

Hi,

for my Trusted Boot project with coreboot, I need to get the OpenSSL crypto
library running with coreboot. I could get the modified elfboot.c compiled
with the OpenSSL calls, but at the linking point with coreboot_ram.o it
crashes because that has the option -nostdlibs. The library needs that
standardlibs and without that option coreboot build will fail.

Here is my actual gcc call:

$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -I /usr/include -L/usr/lib/
-lcrypto -lssl -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld
coreboot_ram.o

Here is the output:

gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -I /usr/include
-L/usr/lib/ -lcrypto -lssl -static -o coreboot_ram -T
/home/sphinx/coreboot/coreboot_o/coreboot-v2/src/config/coreboot_ram.ld
coreboot_ram.o
coreboot_ram.o: In function `measure_elf':
/home/sphinx/coreboot/coreboot_o/coreboot-v2//src/boot/elfboot.c:75:
undefined reference to `EVP_sha256'
/home/sphinx/coreboot/coreboot_o/coreboot-v2//src/boot/elfboot.c:75:
undefined reference to `EVP_Digest'
collect2: ld returned 1 exit status

I need that stdlibs, without it can't find my library.

Any chance how i could get this running?

Regards,

René

[ron minnich]

This is interesting, it's the second note today speculating that we
need to compile with -lgcc.

I think that's a bad approach, as we learned in the early days. It is
too easy to link in libgcc code that expects a full OS environment and
not realize you have done so.

I think you should use the 'ar' tool to extract the .o files you need
from libgcc and link against those.

ron

[Stefan Reinauer]

On 7/27/09 5:22 PM, ron minnich wrote:
> This is interesting, it's the second note today speculating that we
> need to compile with -lgcc.

Which is especially weird since we link against libgcc already.
> I think that's a bad approach, as we learned in the early days. It is
> too easy to link in libgcc code that expects a full OS environment and
> not realize you have done so.

Yes, we should drop libgcc linking, but x86emu wants it for the 64bit
division, too..

René, interesting approach.. Are you checking signatures of the payload?
Out of curiosity .. Is there a reason why the signature checking is not done in the payload itself? That might be easier... There's a grub2 version out there that we made a year or two ago that does signature checking of binaries. Back then we skipped checking the payload, since if it's possible to exchange the payload, it's possible to exchange the rest of the rom code too, in many cases.

Stefan

[ron minnich]

On Mon, Jul 27, 2009 at 8:49 AM, Stefan Reinauer wrote:
> On 7/27/09 5:22 PM, ron minnich wrote:
> > This is interesting, it's the second note today speculating that we
> > need to compile with -lgcc.
>
> Which is especially weird since we link against libgcc already.

ow. I have not been paying attention again. I thought we did the
nostdlibs thing. Sorry.
> Yes, we should drop libgcc linking, but x86emu wants it for the 64bit
> division, too..

oops. Missed that.
ron

[René Reuter]

Thank you all for your help. The demo is tomorrow and i couldn't get it
running. Tried everything but coreboot_ram.o wouldn't link.

To your suggestions:

- To measure direct in the payload is not really acceptable, cause you
have to change every payload and for my concept you have to measure every
possible payload which could come
     - Another library with SHA-2 family is hard too find and I can't use
any untrusted or unmaintained code in my thesis, but thanks for that.

Hopefully in future, it will be easier to link foreign packages in Coreboot.

Regards,

René

2009/7/27 ron minnich
> On Mon, Jul 27, 2009 at 8:49 AM, Stefan Reinauer
> wrote:
> > On 7/27/09 5:22 PM, ron minnich wrote:
> > > This is interesting, it's the second note today speculating that we
> > > need to compile with -lgcc.
> >
> > Which is especially weird since we link against libgcc already.
>
> ow. I have not been paying attention again. I thought we did the
> nostdlibs thing. Sorry.
> > Yes, we should drop libgcc linking, but x86emu wants it for the 64bit
> > division, too..
>
> oops. Missed that.
> ron

[Carl-Daniel Hailfinger]

On 28.07.2009 11:36, René Reuter wrote:
> Thank you all for your help. The demo is tomorrow and i couldn't get it
> running. Tried everything but coreboot_ram.o wouldn't link.

Did you look at my response? It even has a hint on how to fix this.

Regards,
Carl-Daniel

[René Reuter]

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.

Regards,

René

2009/7/28 Carl-Daniel Hailfinger
> On 28.07.2009 11:36, René Reuter wrote:
> > Thank you all for your help. The demo is tomorrow and i couldn't get it
> > running. Tried everything but coreboot_ram.o wouldn't link.
>
> Did you look at my response? It even has a hint on how to fix this.
>
> Regards,
> Carl-Daniel

[Carl-Daniel Hailfinger]

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

[René Reuter]

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

[René Reuter]

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

[René Reuter]

Sorry didn't used the svn diff tool:

Index: src/mainboard/emulation/qemu-x86/Options.lb
===================================================================
--- src/mainboard/emulation/qemu-x86/Options.lb    (Revision 4200)
+++ src/mainboard/emulation/qemu-x86/Options.lb    (Arbeitskopie)
@@ -37,6 +37,7 @@
 uses OBJCOPY
 uses CONFIG_PCI_ROM_RUN
 uses CONFIG_PCI_OPTION_ROM_RUN_VM86
+uses CONFIG_GDB_STUB

uses CONFIG_CONSOLE_SERIAL8250
 uses USE_DCACHE_RAM
@@ -51,7 +52,6 @@
 default DEFAULT_CONSOLE_LOGLEVEL=8
 default MAXIMUM_CONSOLE_LOGLEVEL=8
 default CONFIG_CBFS=0
-
 ## ROM_SIZE is the size of boot ROM that this board will use.
 default ROM_SIZE  = 256*1024

@@ -124,5 +124,5 @@
 ##
 default CC="$(CROSS_COMPILE)gcc -m32"
 default HOSTCC="gcc"
-
+default CONFIG_GDB_STUB=1
 end
Index: src/boot/elfboot.c
===================================================================
--- src/boot/elfboot.c    (Revision 4200)
+++ src/boot/elfboot.c    (Arbeitskopie)
@@ -27,6 +27,8 @@
 #include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
+#include <openssl/sha.h>
+#include <openssl/evp.h>

/* Maximum physical address we can use for the coreboot bounce buffer.
  */
@@ -34,9 +36,14 @@
 #define MAX_ADDR -1UL
 #endif

+#define SHA256_DIGEST_LENGTH    32
+
 extern unsigned char _ram_seg;
 extern unsigned char _eram_seg;

+static void measure_elf(unsigned char *header, size_t length);
+static int measure_and_extend(unsigned char hash);
+
 struct segment {
     struct segment *next;
     struct segment *prev;
@@ -61,6 +68,30 @@
     unsigned short ip_checksum;
 };

+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);
+         //   if (memcmp(md,header,sizeof(header)))
+         //   {   fflush(stdout);
+         //       fprintf(stderr,"\nMemcpy failed.\n");
+         //       return 1;
+         //   }
+        // unsigned char hash = fflush(stdout);
+
+         //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;
+}
+
 int verify_ip_checksum(
     struct verify_callback *vcb,
     Elf_ehdr *ehdr, Elf_phdr *phdr, struct segment *head)
@@ -500,6 +531,7 @@
                 len = ptr->s_filesz;
             }
             memcpy(dest, &header[start_offset], len);
+                        measure_elf(&header[start_offset], len); //Pass the
elf code to the measurement function
             dest += len;
         }

Index: src/config/Config.lb
===================================================================
--- src/config/Config.lb    (Revision 4200)
+++ src/config/Config.lb    (Arbeitskopie)
@@ -10,7 +10,7 @@
 makedefine GCC_INC_DIR := $(shell LC_ALL=C $(GCC) -print-search-dirs | sed
-ne "s/install: (.*)/\1include/gp")

makedefine CPPFLAGS := -I$(TOP)/src/include
-I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS)
-makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc
-nostdlib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common
-ffreestanding -fno-builtin -fomit-frame-pointer
+makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -O2 -g
-nostdinc -nostdlib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common
-ffreestanding -fno-builtin -fomit-frame-pointer

if ASSEMBLER_DEBUG
 makedefine DEBUG_CFLAGS := -g -dA -fverbose-asm
Index: src/arch/i386/boot/boot.c
===================================================================
--- src/arch/i386/boot/boot.c    (Revision 4200)
+++ src/arch/i386/boot/boot.c    (Arbeitskopie)
@@ -84,13 +84,13 @@
     adjusted_boot_notes = (unsigned long)&elf_boot_notes;
     adjusted_boot_notes += adjust;

-    printk_spew("entry    = 0x%08lx\n", (unsigned long)entry);
-    printk_spew("lb_start = 0x%08lx\n", lb_start);
-    printk_spew("lb_size  = 0x%08lx\n", lb_size);
-    printk_spew("adjust   = 0x%08lx\n", adjust);
-    printk_spew("buffer   = 0x%08lx\n", buffer);
-    printk_spew("     elf_boot_notes = 0x%08lx\n", (unsigned
long)&elf_boot_notes);
-    printk_spew("adjusted_boot_notes = 0x%08lx\n", adjusted_boot_notes);
+    printk_debug("entry    = 0x%08lx\n", (unsigned long)entry);
+    printk_debug("lb_start = 0x%08lx\n", lb_start);
+    printk_debug("lb_size  = 0x%08lx\n", lb_size);
+    printk_debug("adjust   = 0x%08lx\n", adjust);
+    printk_debug("buffer   = 0x%08lx\n", buffer);
+    printk_debug("     elf_boot_notes = 0x%08lx\n", (unsigned
long)&elf_boot_notes);
+    printk_debug("adjusted_boot_notes = 0x%08lx\n", adjusted_boot_notes);

/* Jump to kernel */
     __asm__ __volatile__(
Index: src/arch/i386/include/stddef.h
===================================================================
--- src/arch/i386/include/stddef.h    (Revision 4200)
+++ src/arch/i386/include/stddef.h    (Arbeitskopie)
@@ -3,8 +3,10 @@

typedef long ptrdiff_t;
 typedef unsigned long size_t;
-typedef long ssize_t;

+// hacked
+//typedef long ssize_t;
+
 typedef int wchar_t;
 typedef unsigned int wint_t;

Regards,

René

[Carl-Daniel Hailfinger]

Hi René,

OpenSSL can't work in the coreboot environment because it requires a
full libc implementation which can't be part of the coreboot_ram stage.

On 28.07.2009 13:55, René Reuter wrote:
> [diff]

Anyway, I wrote what you want from scratch based on the linux kernel
cryptoapi which supports a quite sizable number of hashes, so the
ability to select the hash you want is still there. Unless I'm missing
something, it is for your purposes an equivalent of openssl without the
nasty dependencies.

Patch is attached, works for me.

It would be neat if you could give credit for this (or cite my thesis)
in your thesis.

Regards,
Carl-Daniel

[Peter Stuge]

René Reuter wrote:
> Another library with SHA-2 family is hard too find

LibTom has the code, I've used it in mysql-sha256 and it works well.
http://git.stuge.se/?p=mysql-sha256.git
> and I can't use any untrusted or unmaintained code in my thesis,
> but thanks for that.

This is a very surprising statement from an author on the topic of
trust.

What constitutes untrusted for you? Is upstream OpenSSL the only
trusted code? Or is it debian OpenSSL? (I don't care that the problem
was in debian in particular, it is just an example.)

Why is unmaintained code a problem at all? Did you investigate why
LibTom is unmaintained? I think it matters.

http://it.slashdot.org/comments.pl?sid=191594&cid=15743508 is a good
read too. (Yes, same Tom.)
> Hopefully in future, it will be easier to link foreign packages in
> Coreboot.

Don't hold your breath. I do not expect that this will change much
for reasons described by Carl-Daniel, and in particular any change
should not happen in coreboot.

"Foreign packages" are not written with the boot environment in mind,
thus they do not function well there. This is true also for the very
foundation of open source "foreign packages" namely gcc. The reason
is simple; the boot environment is different enough from an operating
system environment to cause a lot of problems in common assumptions
made in software.

I think you could have gotten some good advice in time to make your
demo run had you gotten in touch earlier during your thesis work. :\

//Peter

[René Reuter]

Thanks again for that advise.

With the help of Carl it's running now and getting a demo running when you
just saw the code for 4 weeks, isn't that easy, but yeah all my fault,
thanks!

René

2009/7/29 Peter Stuge
> René Reuter wrote:
> > Another library with SHA-2 family is hard too find
>
> LibTom has the code, I've used it in mysql-sha256 and it works well.
> http://git.stuge.se/?p=mysql-sha256.git
> > and I can't use any untrusted or unmaintained code in my thesis,
> > but thanks for that.
>
> This is a very surprising statement from an author on the topic of
> trust.
>
> What constitutes untrusted for you? Is upstream OpenSSL the only
> trusted code? Or is it debian OpenSSL? (I don't care that the problem
> was in debian in particular, it is just an example.)
>
> Why is unmaintained code a problem at all? Did you investigate why
> LibTom is unmaintained? I think it matters.
>
> http://it.slashdot.org/comments.pl?sid=191594&cid=15743508 is a good
> read too. (Yes, same Tom.)
> > Hopefully in future, it will be easier to link foreign packages in
> > Coreboot.
>
> Don't hold your breath. I do not expect that this will change much
> for reasons described by Carl-Daniel, and in particular any change
> should not happen in coreboot.
>
> "Foreign packages" are not written with the boot environment in mind,
> thus they do not function well there. This is true also for the very
> foundation of open source "foreign packages" namely gcc. The reason
> is simple; the boot environment is different enough from an operating
> system environment to cause a lot of problems in common assumptions
> made in software.
>
> I think you could have gotten some good advice in time to make your
> demo run had you gotten in touch earlier during your thesis work. :\
>
> //Peter

[ron minnich]

Neat. Please let us know how the demos go, and I'd like to read any
writeups you have on the work.

Thanks

ron

[Carl-Daniel Hailfinger]

On 27.07.2009 13:01, René Reuter wrote:
> for my Trusted Boot project with coreboot, I need to get the OpenSSL crypto
> library running with coreboot. I could get the modified elfboot.c compiled
> with the OpenSSL calls, but at the linking point with coreboot_ram.o it
> crashes because that has the option -nostdlibs. The library needs that
> standardlibs and without that option coreboot build will fail.
>
> Here is the output:
>
> gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -I /usr/include
> -L/usr/lib/ -lcrypto -lssl -static -o coreboot_ram -T
> /home/sphinx/coreboot/coreboot_o/coreboot-v2/src/config/coreboot_ram.ld
> coreboot_ram.o
> coreboot_ram.o: In function `measure_elf':
> /home/sphinx/coreboot/coreboot_o/coreboot-v2//src/boot/elfboot.c:75:
> undefined reference to `EVP_sha256'
> /home/sphinx/coreboot/coreboot_o/coreboot-v2//src/boot/elfboot.c:75:
> undefined reference to `EVP_Digest'
> collect2: ld returned 1 exit status
>
> I need that stdlibs, without it can't find my library.

No, stdlibs will not help. Your problem is that libcrypto is not linked in.
> Any chance how i could get this running?

Make sure libcrypto gets linked in. Hint: with the paths you provided,
it is very unlikely you get the right libcrypto.

Regards,
Carl-Daniel

[Peter Stuge]

René Reuter wrote:
> for my Trusted Boot project with coreboot, I need to get the
> OpenSSL crypto library running with coreboot.

Are you really sure?

There are a couple of other crypto libraries which might be easier to
use in a coreboot setting. Look at LibTom[1] and cryptlib[2] for
example.

//Peter

[1] Unmaintained since 6+ months, the PD code is available at
    http://home.libtom.org/lt_tree.tar.bz2
[2] http://www.cs.auckland.ac.nz/~pgut001/cryptlib/