This package is useful for signing and verifying PE/COFF files for UEFI Secure Boot, and recently for some other tasks like signing and synchronizing EFI variables, etc. If Gentoo ever wants to support Secure Boot, this is probably the package to use. I recommend it, because I contributed to its development (32-bit EFI support) and successfully used it for implementing Secure Boot in Liberté Linux (the first distribution to ship with Secure Boot EFI images, as a basis for trusted boot chain). The package is developed for Ubuntu by Jeremy Kerr <jeremy.kerr@canonical.com>, and AFAIK is now used by Ubuntu for signing its non-CD EFI images.
Created attachment 330672 [details] sbsigntool-0.6.ebuild
Ubuntu package: http://packages.ubuntu.com/source/quantal/utils/sbsigntool Git repository: git://kernel.ubuntu.com/jk/sbsigntool
Comment on attachment 330672 [details] sbsigntool-0.6.ebuild >KEYWORDS="x86 amd64" default to ~arch >IUSE="test" you don't use this, so set to "" >RDEPEND="dev-libs/openssl" >DEPEND="${RDEPEND} > sys-boot/gnu-efi" it only needs gnu-efi at build time ? you sure ? >src_prepare() { > sed -i 's@^\(EFI_ARCH=\$(uname -m\))$@\1 | sed s/i686/ia32/)@' "${S}"/configure.ac pretty sure this is still wrong for cross-compiling. it should be using $host_cpu.
(In reply to comment #3) > default to ~arch Sure, will do in future. :) > >IUSE="test" > > you don't use this, so set to "" It works with FEATURE=test on amd64... There are many tests. On x86 it doesn't work due to toolchain limitations (tests test both supported architectures simultaneously). > it only needs gnu-efi at build time ? you sure ? Yes -- for once, gnu-efi is a static lib, and also sbsigntool only really uses the headers (for PE/COFF structures), nothing is actually linked from .a from what I have seen (it's a non-EFI userspace utility, after all). > >src_prepare() { > > sed -i 's@^\(EFI_ARCH=\$(uname -m\))$@\1 | sed s/i686/ia32/)@' "${S}"/configure.ac > > pretty sure this is still wrong for cross-compiling. it should be using > $host_cpu. Well, configure.ac uses $(uname -m), I just fixed the result for x86. EFI_ARCH is the dir in /usr/include/efi (ia32 or x86_64), that's its only purpose. I think it also doesn't matter for sbsigntool, since it supports both archs -- it's just that one needs the subdir on the include path in order to be able to include efi.h.
(In reply to comment #4) > It works with FEATURE=test on amd64... There are many tests. On x86 it > doesn't work due to toolchain limitations (tests test both supported > architectures simultaneously). You did not rely on USE test(i do not see any constructions like 'if use test', or any test-specific dependencies. So, USE flag probably unneeded. It's removal does not break tests.
(In reply to comment #5) > You did not rely on USE test(i do not see any constructions like 'if use > test', or any test-specific dependencies. So, USE flag probably unneeded. > It's removal does not break tests. You are right, I didn't know that disabling tests support works the other way, via RESTRICT. Attaching updated ebuild, with all the points raised by @vapier addressed: 1. Defaulting to ~arch. 2. Using RESTRICT to disable tests on x86. 3. EFI_ARCH is now assigned as in gnu-efi ebuild. Tested with FEATURES=test on x86 and amd64, with gnu-efi-3.0s.
Created attachment 331798 [details] sbsigntool-0.6.ebuild
(In reply to comment #4) does your gcc support -m64 ? if not, rebuild it and it should work. re-configure, i think you missed the point -- you cannot run `uname`. you must key off the $host_cpu value in configure scripts. otherwise i can't cross-compile this package on a different system. like a ppc or ia64 system. (In reply to comment #7) KEYWORDS should be kept sorted. you can use `ekeyword ~all foo.ebuild`. you should use sed address matching in order to keep things simple: sed -i "/^EFI_ARCH=/s:=.*:=${efi_arch}:" configure.ac
Created attachment 331826 [details] sbsigntool-0.6.ebuild adds more deps and simplifies some code
(In reply to comment #8) > does your gcc support -m64 ? if not, rebuild it and it should work. It does, but something really sinister is going on when compiling .S files used for testing with -m64 -- it fails, and if you start adding -march options, it fails with really weird linking errors. Believe me, I tried to solve it, and e.g. I do succeed to cross-compile an x86_64 kernel on x86 with a "gcc -m64 -march=x86-64" x86_64-gcc wrapper and a few other toolchain symlinks > re-configure, i think you missed the point -- you cannot run `uname`. you > must key off the $host_cpu value in configure scripts. otherwise i can't > cross-compile this package on a different system. like a ppc or ia64 system. I got it, but after the updated sed there is no more uname in configure.ac (and I see you have now copied gnu-efi ARCH dispatch verbatim). > you should use sed address matching in order to keep things simple: > sed -i "/^EFI_ARCH=/s:=.*:=${efi_arch}:" configure.ac Thanks. :)
(In reply to comment #9) > adds more deps and simplifies some code Re util-linux -- I thought there is no need to depend on packages in @system? Or is it not in @system on all archs?
(In reply to comment #10) we should fix that so the tests pass. the expectation is that gcc on a 32bit system can still build & link 64bit code. (In reply to comment #11) "it depends". if you're talking "i need a compiler", or "i need a C library", or "i need `ls` or `mv` or `grep` or `make`", then no, adding deps on those is wrong. in this case, the util-linux dep is there because we use -luuid.
(In reply to comment #12) > we should fix that so the tests pass. the expectation is that gcc on a > 32bit system can still build & link 64bit code. The problem is upstream: fixing it = working on the package. I will post more details later (with the weird errors) -- maybe you will know how to fix, but still -- it's upstream. > in this case, the util-linux dep is there because we use -luuid. Sure, I noticed -luuid originally, just didn't think there should be a dep.
Hi, there is one additional sed needed to supposedly make 64-bit tests work on x86: sed -i "s/-m64$/& -march=x86-64/" tests/Makefile.am However, here is the problem: make[2]: Entering directory `/var/tmp/portage/app-crypt/sbsigntool-0.6/work/sbsigntool-0.6/tests' i686-pc-linux-gnu-gcc -m64 -march=x86-64 -c -o test-x86_64.o test.S i686-pc-linux-gnu-gcc <CFLAGS here> -nostdlib -T ./test-x86_64.lds -o test-x86_64.elf test-x86_64.o i686-pc-linux-gnu-objcopy -j .text -j .sdata -j .data \ -j .dynamic -j .dynsym -j .rel \ -j .rela -j .reloc \ --target=efi-app-x86-64 test-x86_64.elf test-x86_64.pecoff i686-pc-linux-gnu-objcopy:test-x86_64.elf: Invalid bfd target So 32-bit objcopy apparently doesn't support efi-app-x86-64 object format.
Created attachment 332076 [details] sbsigntool-0.6.ebuild Updated ebuild with -march=x86-64 added for -m64 switches (tests still don't work on x86 due to objcopy limitation).
(In reply to comment #14) we might have to pass more targets to --enable-targets for x86 binutils. we force all gcc installs to be biarch, so having binutils be biarch too is OK.
(In reply to comment #16) > we might have to pass more targets to --enable-targets for x86 binutils. we > force all gcc installs to be biarch, so having binutils be biarch too is OK. With USE=multitarget (--enable-targets=all --enable-64-bit-bfd) the tests indeed work, but just --enable-64-bit-bfd is not enough.
(In reply to comment #17) right ... i meant something like --enable-targets=i686-linux-gnu,x86_64-linux-gnu
So this is now a bug in toolchain biarch support, no? sbsigntool ebuild is ready?
By the way, it seems that by emerging binutils with USE=multitarget, then without again, I have lost the ability to cross-compile to x86-64. Remerging binutils or gcc doesn't help. # gcc -m64 -march=x86-64 -c -o a a.c Assembler messages: Fatal error: no compiled in support for x86_64 Note the unusual message -- e.g., on another box where gcc 4.5.3 was compiled before biarch support was added to toolchain eclasses: a.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
(In reply to comment #20) > By the way, it seems that by emerging binutils with USE=multitarget, then > without again, I have lost the ability to cross-compile to x86-64. Remerging > binutils or gcc doesn't help. Created bug #446946.
(In reply to comment #18) > --enable-targets=i686-linux-gnu,x86_64-linux-gnu This does indeed fix the problem with sbsigntool tests on x86 (using the updated ebuild I uploaded). Curiously, "qlist -e binutils" results in same file list as with just --enable-64-bit-bfd (which doesn't fix the problem -- I checked again).
will also need http://sourceware.org/ml/binutils/2012-12/msg00245.html in binutils
should be all set now in the tree; thanks for the report! Commit message: New package http://sources.gentoo.org/app-crypt/sbsigntool/sbsigntool-0.6.ebuild?rev=1.1
Great!
