Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
UEFI Secure boot using qemu-kvm
136 views
Skip to first unread message
James Bottomley
Jun 27, 2012, 1:34:18 PM6/27/12
to linux-kernel, Jonathan Corbet
Hi Everyone,
The purpose of this email is to widen the pool of people who are playing
with UEFI Secure boot. The Linux Foundation Technical Advisory Board
have been looking into this because it turns out to be rather difficult
to lay your hands on real UEFI Secure Boot enabled hardware. Many
thanks are due to the Intel Tianocore project which recently added the
secure boot facility to their UEFI rom images.
What I have done:
I've built the tianocore boot system (along with a README describing how
to use it) and placed it in the opensuse build system so you can
download it (the OVMF package) from:
http://download.opensuse.org/repositories/home:/jejb1:/UEFI/openSUSE_12.1/
(it has no OS depends, so the rpm should be installable on almost any
distro ... including debian via alien). Also in this repository is
Jeremy Kerr's sbsigntools which can be used to sign efi binaries.
While doing all of this, I discovered a bug in the gnu-efi environment
we usually use to build efi binaries on Linux (the fix is to the loader
script). I've got an example of how to use the fixed script and a
builder for a LockDown.efi binary that will take a secure boot platform
in setup mode and install a Platform Key and Key Exchange Key and enable
secure boot (if you type make, it will build the PK and KEK
certificates, plus roll them into the binary).
http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;a=summary
I'll probably add other useful efi utilities as the project progresses.
I should note that currently Jeremy's efi signing tools only really do
x86_64 binaries, so the whole project is based on that architecture.
The current state is that I've managed to lock down the secure boot
virtual platform with my own PK and KEK and verified that I can generate
signed efi binaries that will run on it (and that it will refuse to run
unsigned efi binaries). Finally I've demonstrated that I can sign
elilo.efi (this has to be built specially because of the bug in gnu-efi)
and have it boot an unsigned linux kernel when the platform is in secure
mode (I've booted up to an initrd root prompt).
I'm releasing this now because interest in UEFI Secure Boot is rising,
particularly amongst the Linux Distributions which don't have access to
UEFI secure boot hardware, so having a virtual platform should allow
them to experiment with coming up with their own solutions.
Please remember, though, that all this is very alpha. The Tianocore
firmware that does secure boot is only a few weeks old, and the
sbsigning tools weren't really working up until yesterday, so this is
very far from rock solid.
James
PS if you don't understand terms like Platform Key, or Setup Mode in the
above, please ask google for help. Secure boot is very technical, but
there have been some good blog posts explaining the basics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
The purpose of this email is to widen the pool of people who are playing
with UEFI Secure boot. The Linux Foundation Technical Advisory Board
have been looking into this because it turns out to be rather difficult
to lay your hands on real UEFI Secure Boot enabled hardware. Many
thanks are due to the Intel Tianocore project which recently added the
secure boot facility to their UEFI rom images.
What I have done:
I've built the tianocore boot system (along with a README describing how
to use it) and placed it in the opensuse build system so you can
download it (the OVMF package) from:
http://download.opensuse.org/repositories/home:/jejb1:/UEFI/openSUSE_12.1/
(it has no OS depends, so the rpm should be installable on almost any
distro ... including debian via alien). Also in this repository is
Jeremy Kerr's sbsigntools which can be used to sign efi binaries.
While doing all of this, I discovered a bug in the gnu-efi environment
we usually use to build efi binaries on Linux (the fix is to the loader
script). I've got an example of how to use the fixed script and a
builder for a LockDown.efi binary that will take a secure boot platform
in setup mode and install a Platform Key and Key Exchange Key and enable
secure boot (if you type make, it will build the PK and KEK
certificates, plus roll them into the binary).
http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;a=summary
I'll probably add other useful efi utilities as the project progresses.
I should note that currently Jeremy's efi signing tools only really do
x86_64 binaries, so the whole project is based on that architecture.
The current state is that I've managed to lock down the secure boot
virtual platform with my own PK and KEK and verified that I can generate
signed efi binaries that will run on it (and that it will refuse to run
unsigned efi binaries). Finally I've demonstrated that I can sign
elilo.efi (this has to be built specially because of the bug in gnu-efi)
and have it boot an unsigned linux kernel when the platform is in secure
mode (I've booted up to an initrd root prompt).
I'm releasing this now because interest in UEFI Secure Boot is rising,
particularly amongst the Linux Distributions which don't have access to
UEFI secure boot hardware, so having a virtual platform should allow
them to experiment with coming up with their own solutions.
Please remember, though, that all this is very alpha. The Tianocore
firmware that does secure boot is only a few weeks old, and the
sbsigning tools weren't really working up until yesterday, so this is
very far from rock solid.
James
PS if you don't understand terms like Platform Key, or Setup Mode in the
above, please ask google for help. Secure boot is very technical, but
there have been some good blog posts explaining the basics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
Jun 27, 2012, 2:15:16 PM6/27/12
to James Bottomley, linux-kernel, Jonathan Corbet
On Wed, Jun 27, 2012 at 06:34:05PM +0100, James Bottomley wrote:
> The purpose of this email is to widen the pool of people who are playing
> with UEFI Secure boot. The Linux Foundation Technical Advisory Board
> have been looking into this because it turns out to be rather difficult
> to lay your hands on real UEFI Secure Boot enabled hardware.
http://tunnelmountain.net/ is the canonical source, but I believe that
> The purpose of this email is to widen the pool of people who are playing
> with UEFI Secure boot. The Linux Foundation Technical Advisory Board
> have been looking into this because it turns out to be rather difficult
> to lay your hands on real UEFI Secure Boot enabled hardware.
these are now out of stock and waiting for Intel to finish the
firmware for the replacement.
> The current state is that I've managed to lock down the secure boot
> virtual platform with my own PK and KEK and verified that I can generate
> signed efi binaries that will run on it (and that it will refuse to run
> unsigned efi binaries). Finally I've demonstrated that I can sign
> elilo.efi (this has to be built specially because of the bug in gnu-efi)
> and have it boot an unsigned linux kernel when the platform is in secure
> mode (I've booted up to an initrd root prompt).
expectations of various vendors
(http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx
would be unnecessary if you're supporting unsigned kernels, for
example). There's no public cross-vendor guidance on this, but I'm
trying to get that rectified.
As well as sbsign there's also https://github.com/vathpela/pesign for
anyone stuck relying on nss rather than openssl for awkward regulatory
reasons.
--
Matthew Garrett | mj...@srcf.ucam.org
James Bottomley
Jun 27, 2012, 3:35:18 PM6/27/12
to Matthew Garrett, linux-kernel, Jonathan Corbet
process; how did you build it?
However, sbsign (with four extra patches I've sent to Jeremy) seems to
be built and working.
James
Matthew Garrett
Jun 27, 2012, 3:38:15 PM6/27/12
to James Bottomley, linux-kernel, Jonathan Corbet
On Wed, Jun 27, 2012 at 08:35:04PM +0100, James Bottomley wrote:
> I've tried to build pesign, but I have huge problems with the make
> process; how did you build it?
I checked it out and ran make. What problems ar eyou seeing?
> I've tried to build pesign, but I have huge problems with the make
> process; how did you build it?
--
Matthew Garrett | mj...@srcf.ucam.org
James Bottomley
Jun 27, 2012, 3:53:39 PM6/27/12
to Matthew Garrett, linux-kernel, Jonathan Corbet
On Wed, 2012-06-27 at 20:38 +0100, Matthew Garrett wrote:
> On Wed, Jun 27, 2012 at 08:35:04PM +0100, James Bottomley wrote:
>
> > I've tried to build pesign, but I have huge problems with the make
> > process; how did you build it?
>
> I checked it out and ran make. What problems ar eyou seeing?
jejb@dabdike> make
> On Wed, Jun 27, 2012 at 08:35:04PM +0100, James Bottomley wrote:
>
> > I've tried to build pesign, but I have huge problems with the make
> > process; how did you build it?
>
> I checked it out and ran make. What problems ar eyou seeing?
make -C include TOPDIR=/home/jejb/git/pesign
SRCDIR=/home/jejb/git/pesign/include/ ARCH=x86_64
make[1]: Entering directory `/home/jejb/git/pesign/include'
make -C libdpe TOPDIR=/home/jejb/git/pesign
SRCDIR=/home/jejb/git/pesign/libdpe/ ARCH=x86_64
make[2]: Entering directory `/home/jejb/git/pesign/include/libdpe'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/jejb/git/pesign/include/libdpe'
make[1]: Leaving directory `/home/jejb/git/pesign/include'
make -C libdpe TOPDIR=/home/jejb/git/pesign
SRCDIR=/home/jejb/git/pesign/libdpe/ ARCH=x86_64
make[1]: Entering directory `/home/jejb/git/pesign/libdpe'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jejb/git/pesign/libdpe'
make -C src TOPDIR=/home/jejb/git/pesign
SRCDIR=/home/jejb/git/pesign/src/ ARCH=x86_64
make[1]: Entering directory `/home/jejb/git/pesign/src'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jejb/git/pesign/src'
make -C util TOPDIR=/home/jejb/git/pesign
SRCDIR=/home/jejb/git/pesign/util/ ARCH=x86_64
make[1]: Entering directory `/home/jejb/git/pesign/util'
/usr/bin/gcc -I/home/jejb/git/pesign/include -g -O0 -fpic -Wall
-fshort-wchar -fno-strict-aliasing -fno-merge-constants --std=gnu99
-D_GNU_SOURCE -DEFI_FUNCTION_WRAPPER -mno-red-zone -I/usr/include/efi/
-I/usr/include/efi/x86_64/ -I/usr/include/efi/protocol -fpic
-fshort-wchar -fno-reorder-functions -fno-strict-aliasing
-fno-merge-constants -mno-red-zone -Wimplicit-function-declaration
-DCONFIG_x86_64 -D__UEFI__ -c setupsb.c -o setupsb.o
In file included from /usr/include/efi/efi.h:35:0,
from setupsb.c:2:
/usr/include/efi/x86_64/efibind.h:88:1: error: unknown type name
‘uint64_t’
/usr/include/efi/x86_64/efibind.h:89:1: error: unknown type name
‘int64_t’
/usr/include/efi/x86_64/efibind.h:92:5: error: unknown type name
‘uint32_t’
/usr/include/efi/x86_64/efibind.h:93:5: error: unknown type name
‘int32_t’
/usr/include/efi/x86_64/efibind.h:96:1: error: unknown type name
‘uint16_t’
/usr/include/efi/x86_64/efibind.h:97:1: error: unknown type name
‘int16_t’
/usr/include/efi/x86_64/efibind.h:98:1: error: unknown type name
‘uint8_t’
/usr/include/efi/x86_64/efibind.h:99:1: error: unknown type name
‘int8_t’
/usr/include/efi/x86_64/efibind.h:106:1: error: unknown type name
‘int64_t’
/usr/include/efi/x86_64/efibind.h:107:1: error: unknown type name
‘uint64_t’
setupsb.c: In function ‘dumphex’:
setupsb.c:30:3: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:33:4: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:37:3: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘dumphex_str’:
setupsb.c:46:3: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:49:4: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:53:3: warning: passing argument 1 of ‘Print’ from incompatible
pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘get_args’:
setupsb.c:62:27: error: ‘EFI_BOOT_SERVICES’ has no member named
‘OpenProtocol’
setupsb.c:66:5: error: ‘EFI_OPEN_PROTOCOL_GET_PROTOCOL’ undeclared
(first use in this function)
setupsb.c:66:5: note: each undeclared identifier is reported only once
for each function it appears in
setupsb.c:73:22: error: ‘EFI_BOOT_SERVICES’ has no member named
‘CloseProtocol’
setupsb.c: In function ‘pk_is_populated’:
setupsb.c:86:3: warning: passing argument 1 of ‘LibGetVariableAndSize’
from incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:511:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘kek_is_populated’:
setupsb.c:100:3: warning: passing argument 1 of ‘LibGetVariableAndSize’
from incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:511:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘db_is_populated’:
setupsb.c:114:3: warning: passing argument 1 of ‘LibGetVariableAndSize’
from incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:511:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘make_variable’:
setupsb.c:143:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:153:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘usage’:
setupsb.c:172:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:176:8: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:177:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:178:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:179:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:180:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:181:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:182:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: In function ‘has_force’:
setupsb.c:190:3: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c: At top level:
setupsb.c:215:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:215:2: warning: (near initialization for ‘hashes[0].name’)
[enabled by default]
setupsb.c:216:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:216:2: warning: (near initialization for ‘hashes[1].name’)
[enabled by default]
setupsb.c:217:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:217:2: warning: (near initialization for ‘hashes[2].name’)
[enabled by default]
setupsb.c:218:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:218:2: warning: (near initialization for ‘hashes[3].name’)
[enabled by default]
setupsb.c: In function ‘get_hash’:
setupsb.c:235:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:238:3: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:241:6: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:242:5: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:256:5: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:257:5: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:265:5: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:266:5: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:277:6: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:279:6: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:290:2: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘get_file’:
setupsb.c:297:2: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘set_pk’:
setupsb.c:312:4: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:319:3: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:320:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘set_db_helper’:
setupsb.c:364:4: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘set_db’:
setupsb.c:394:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘set_dbx’:
setupsb.c:402:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘set_kek’:
setupsb.c:410:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘append_db’:
setupsb.c:419:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘append_dbx’:
setupsb.c:427:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘append_kek’:
setupsb.c:435:5: warning: passing argument 6 of ‘set_db_helper’ from
incompatible pointer type [enabled by default]
setupsb.c:350:1: note: expected ‘CHAR16 *’ but argument is of type
‘short unsigned int *’
setupsb.c: In function ‘append_pk’:
setupsb.c:441:2: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:442:2: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘clear_db’:
setupsb.c:466:4: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:467:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: In function ‘clear_kek’:
setupsb.c:499:4: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:500:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c: At top level:
setupsb.c:517:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:517:2: warning: (near initialization for ‘actions[0].name’)
[enabled by default]
setupsb.c:517:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:517:2: warning: (near initialization for ‘actions[0].db’)
[enabled by default]
setupsb.c:518:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:518:2: warning: (near initialization for ‘actions[1].name’)
[enabled by default]
setupsb.c:518:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:518:2: warning: (near initialization for ‘actions[1].db’)
[enabled by default]
setupsb.c:519:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:519:2: warning: (near initialization for ‘actions[2].name’)
[enabled by default]
setupsb.c:519:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:519:2: warning: (near initialization for ‘actions[2].db’)
[enabled by default]
setupsb.c:520:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:520:2: warning: (near initialization for ‘actions[3].name’)
[enabled by default]
setupsb.c:520:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:520:2: warning: (near initialization for ‘actions[3].db’)
[enabled by default]
setupsb.c:521:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:521:2: warning: (near initialization for ‘actions[4].name’)
[enabled by default]
setupsb.c:521:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:521:2: warning: (near initialization for ‘actions[4].db’)
[enabled by default]
setupsb.c:522:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:522:2: warning: (near initialization for ‘actions[5].name’)
[enabled by default]
setupsb.c:522:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:522:2: warning: (near initialization for ‘actions[5].db’)
[enabled by default]
setupsb.c:523:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:523:2: warning: (near initialization for ‘actions[6].name’)
[enabled by default]
setupsb.c:523:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:523:2: warning: (near initialization for ‘actions[6].db’)
[enabled by default]
setupsb.c:524:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:524:2: warning: (near initialization for ‘actions[7].name’)
[enabled by default]
setupsb.c:524:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:524:2: warning: (near initialization for ‘actions[7].db’)
[enabled by default]
setupsb.c:525:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:525:2: warning: (near initialization for ‘actions[8].name’)
[enabled by default]
setupsb.c:525:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:525:2: warning: (near initialization for ‘actions[8].db’)
[enabled by default]
setupsb.c:526:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:526:2: warning: (near initialization for ‘actions[9].name’)
[enabled by default]
setupsb.c:526:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:526:2: warning: (near initialization for ‘actions[9].db’)
[enabled by default]
setupsb.c:527:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:527:2: warning: (near initialization for ‘actions[10].name’)
[enabled by default]
setupsb.c:527:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:527:2: warning: (near initialization for ‘actions[10].db’)
[enabled by default]
setupsb.c:528:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:528:2: warning: (near initialization for ‘actions[11].name’)
[enabled by default]
setupsb.c:528:2: warning: initialization from incompatible pointer type
[enabled by default]
setupsb.c:528:2: warning: (near initialization for ‘actions[11].db’)
[enabled by default]
setupsb.c: In function ‘efi_main’:
setupsb.c:545:3: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:550:3: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:553:3: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:557:3: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:558:5: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:559:5: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:560:5: warning: passing argument 2 of ‘StrCmp’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:200:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
setupsb.c:569:2: warning: overflow in implicit constant conversion
[-Woverflow]
setupsb.c:583:3: warning: passing argument 1 of ‘Print’ from
incompatible pointer type [enabled by default]
/usr/include/efi/efilib.h:388:1: note: expected ‘CHAR16 *’ but argument
is of type ‘short unsigned int *’
make[1]: *** [setupsb.o] Error 1
make[1]: Leaving directory `/home/jejb/git/pesign/util'
make: *** [util] Error 2
James
Matthew Garrett
Jun 27, 2012, 4:01:10 PM6/27/12
to James Bottomley, linux-kernel, Jonathan Corbet
On Wed, Jun 27, 2012 at 08:53:29PM +0100, James Bottomley wrote:
> /usr/include/efi/x86_64/efibind.h:88:1: error: unknown type name
> ‘uint64_t’
Ok, so some difference in toolchains is pulling in stdint.h for me but
> /usr/include/efi/x86_64/efibind.h:88:1: error: unknown type name
> ‘uint64_t’
not for you.
--
Matthew Garrett | mj...@srcf.ucam.org
joeyli
Jun 28, 2012, 6:01:56 AM6/28/12
to JBott...@parallels.com, linux-...@vger.kernel.org
Hi James,
On Wed, Jun 27, 2012 at 06:34:05PM +0100, James Bottomley wrote:
> The purpose of this email is to widen the pool of people who are playing
> with UEFI Secure boot. The Linux Foundation Technical Advisory Board
> have been looking into this because it turns out to be rather difficult
> to lay your hands on real UEFI Secure Boot enabled hardware.
I am following your approach to reproduce your UEFI environment with
qemu-kvm. After run qemu-system-x86_64 the kvm launched and go to UEFI
shell success. So far so good!
But, I got a problem is the keyboard layout is not US keyboard, So I
need build a mapping table for reference when key-in any letter:
[ e
/ x
s i
enter t
down enter
page up down
..
Did you meet this issue on your side?
Thanks a lot!
Joey Lee
On Wed, Jun 27, 2012 at 06:34:05PM +0100, James Bottomley wrote:
> The purpose of this email is to widen the pool of people who are playing
> with UEFI Secure boot. The Linux Foundation Technical Advisory Board
> have been looking into this because it turns out to be rather difficult
> to lay your hands on real UEFI Secure Boot enabled hardware.
qemu-kvm. After run qemu-system-x86_64 the kvm launched and go to UEFI
shell success. So far so good!
But, I got a problem is the keyboard layout is not US keyboard, So I
need build a mapping table for reference when key-in any letter:
[ e
/ x
s i
enter t
down enter
page up down
..
Did you meet this issue on your side?
Thanks a lot!
Joey Lee
James Bottomley
Jun 28, 2012, 6:22:54 AM6/28/12
to joeyli, JBott...@parallels.com, linux-...@vger.kernel.org
joeyli <jl...@suse.com> wrote:
>Hi James,
>
>On Wed, Jun 27, 2012 at 06:34:05PM +0100, James Bottomley wrote:
>
>> The purpose of this email is to widen the pool of people who are
>playing
>> with UEFI Secure boot. The Linux Foundation Technical Advisory Board
>> have been looking into this because it turns out to be rather
>difficult
>> to lay your hands on real UEFI Secure Boot enabled hardware.
>
>
>I am following your approach to reproduce your UEFI environment with
>qemu-kvm. After run qemu-system-x86_64 the kvm launched and go to UEFI
>shell success. So far so good!
>
>But, I got a problem is the keyboard layout is not US keyboard, So I
>need build a mapping table for reference when key-in any letter:
>
>[ e
>/ x
>s i
>enter t
>down enter
>page up down
>
>
>Did you meet this issue on your side?
Well no. I've got a US keyboard. You probably need the keymap directory from qemu-kvm.
>
>Did you meet this issue on your side?
The best thing is probably to copy all the qemu files to a new directory and then copy in the qemu-ovmf ones (assuming standard qemu-kvm works for you).
James
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
joeyli
Jun 28, 2012, 6:25:32 AM6/28/12
to JBott...@parallels.com, linux-...@vger.kernel.org
Hi James,
於 四，2012-06-28 於 18:11 +0800，lee joey 提到：
> ...
machine that setup environment then run qemu-kvm.
When direct launch qemu-kvm on the machine, there have no keyboard
layout problem. Not sure this problem is dependent to qemu or UEFI
image.
於 四，2012-06-28 於 18:11 +0800，lee joey 提到：
>
>
> Did you meet this issue on your side?
>
I just found this issue only happen on when I used ssh connect to the
>
> Did you meet this issue on your side?
>
machine that setup environment then run qemu-kvm.
When direct launch qemu-kvm on the machine, there have no keyboard
layout problem. Not sure this problem is dependent to qemu or UEFI
image.
joeyli
Jun 28, 2012, 6:50:46 AM6/28/12
to James Bottomley, linux-...@vger.kernel.org
於 四，2012-06-28 於 11:22 +0100，James Bottomley 提到：
Yes, I just found the problem happen on using SSH login to the machine
that have qemu-kvm and launch it with UEFI shell.
If I direct launch kvm on the machine, everything is OK!
I already import your PK.cer and KEK.cer and run
HelloWorld.efi/HelloWorld-signed.efi to verify the secure boot success.
When running non-signed file, shell show up:
Error reported: Access Denied
Thanks a lot for your document and RPMs on OBS, it's really useful to me
for verify secure boot.
Regards
Joey Lee
that have qemu-kvm and launch it with UEFI shell.
If I direct launch kvm on the machine, everything is OK!
I already import your PK.cer and KEK.cer and run
HelloWorld.efi/HelloWorld-signed.efi to verify the secure boot success.
When running non-signed file, shell show up:
Error reported: Access Denied
Thanks a lot for your document and RPMs on OBS, it's really useful to me
for verify secure boot.
Regards
Joey Lee
Alex Elsayed
Jun 28, 2012, 6:50:53 PM6/28/12
to linux-...@vger.kernel.org
Matthew Garrett wrote:
> On Wed, Jun 27, 2012 at 08:53:29PM +0100, James Bottomley wrote:
>> /usr/include/efi/x86_64/efibind.h:88:1: error: unknown type name
>> ‘uint64_t’
>
> Ok, so some difference in toolchains is pulling in stdint.h for me but
> not for you.
>
If James is on GCC 4.7 and you are on 4.6, that would explain it - 4.7
> On Wed, Jun 27, 2012 at 08:53:29PM +0100, James Bottomley wrote:
>> /usr/include/efi/x86_64/efibind.h:88:1: error: unknown type name
>> ‘uint64_t’
>
> Ok, so some difference in toolchains is pulling in stdint.h for me but
> not for you.
>
dropped some implicit #includes AIUI.
joeyli
Jun 30, 2012, 12:22:50 PM6/30/12
to linux-...@vger.kernel.org, JBott...@parallels.com
於 四，2012-06-28 於 18:24 +0800，joeyli 提到：
Base on James's approach, wrote a wiki page have steps and screenshot:
http://en.opensuse.org/KVM/UEFI_Secure_boot_using_qemu-kvm
Thanks
http://en.opensuse.org/KVM/UEFI_Secure_boot_using_qemu-kvm
Thanks
Khalid Aziz
Jul 12, 2012, 6:18:02 PM7/12/12
to joeyli, linux-...@vger.kernel.org, JBott...@parallels.com, linu...@vger.kernel.org
I Tried to follow the steps Joey had written down (Thanks for doing
that!) on Ubuntu 12.04 and ran into some problems. Here is what I had to
do differently to get it to work:
- Install libssl-dev
- Use "sudo alien --to-deb sbsigntools-0.3-1.1.x86_64.rpm" to convert
sbsigntools package and "dpkg -i" the resulting deb package
- Before building efitools, edit Make.rules and replace "/usr/lib64"
with "/usr/lib"
- Run "make PK.h DB.h KEK.h" followed by "make". Make will fail to build
Loader.so with error being __stack_chk_fail is undefined. Ubuntu's
version of gcc enables stack check by default and adding
-fno-stack-protector to CFLAGS did not help. I haven't figured this one
out yet but Helloworld.efi builds correctly.
- Run "make HelloWorld-kek-signed.efi" to build signed version of hello
world.
- At this point I could fire up qemu and run the signed and unsigned
versions of hello world (HelloWorld-kek-signed.efi and HelloWorld.efi)
with secure boot disabled and enabled after importing PK and KEK as Joey
showed in his instructions.
Hope this helps someone who is trying this on Ubuntu. Now on to figuring
out how to build Loader.efi.
--
Khalid Aziz <khali...@hp.com>
that!) on Ubuntu 12.04 and ran into some problems. Here is what I had to
do differently to get it to work:
- Install libssl-dev
- Use "sudo alien --to-deb sbsigntools-0.3-1.1.x86_64.rpm" to convert
sbsigntools package and "dpkg -i" the resulting deb package
- Before building efitools, edit Make.rules and replace "/usr/lib64"
with "/usr/lib"
- Run "make PK.h DB.h KEK.h" followed by "make". Make will fail to build
Loader.so with error being __stack_chk_fail is undefined. Ubuntu's
version of gcc enables stack check by default and adding
-fno-stack-protector to CFLAGS did not help. I haven't figured this one
out yet but Helloworld.efi builds correctly.
- Run "make HelloWorld-kek-signed.efi" to build signed version of hello
world.
- At this point I could fire up qemu and run the signed and unsigned
versions of hello world (HelloWorld-kek-signed.efi and HelloWorld.efi)
with secure boot disabled and enabled after importing PK and KEK as Joey
showed in his instructions.
Hope this helps someone who is trying this on Ubuntu. Now on to figuring
out how to build Loader.efi.
--
Khalid Aziz <khali...@hp.com>
James Bottomley
Jul 19, 2012, 5:41:46 AM7/19/12
to Khalid Aziz, joeyli, linux-...@vger.kernel.org, linu...@vger.kernel.org
On Thu, 2012-07-12 at 16:17 -0600, Khalid Aziz wrote:
> I Tried to follow the steps Joey had written down (Thanks for doing
> that!) on Ubuntu 12.04 and ran into some problems. Here is what I had to
> do differently to get it to work:
>
> - Install libssl-dev
>
> - Use "sudo alien --to-deb sbsigntools-0.3-1.1.x86_64.rpm" to convert
> sbsigntools package and "dpkg -i" the resulting deb package
>
> - Before building efitools, edit Make.rules and replace "/usr/lib64"
> with "/usr/lib"
>
> - Run "make PK.h DB.h KEK.h" followed by "make". Make will fail to build
> Loader.so with error being __stack_chk_fail is undefined. Ubuntu's
> version of gcc enables stack check by default and adding
> -fno-stack-protector to CFLAGS did not help. I haven't figured this one
> out yet but Helloworld.efi builds correctly.
Actually, I just ran into this too. Apparently libefi.a needs to be
> I Tried to follow the steps Joey had written down (Thanks for doing
> that!) on Ubuntu 12.04 and ran into some problems. Here is what I had to
> do differently to get it to work:
>
> - Install libssl-dev
>
> - Use "sudo alien --to-deb sbsigntools-0.3-1.1.x86_64.rpm" to convert
> sbsigntools package and "dpkg -i" the resulting deb package
>
> - Before building efitools, edit Make.rules and replace "/usr/lib64"
> with "/usr/lib"
>
> - Run "make PK.h DB.h KEK.h" followed by "make". Make will fail to build
> Loader.so with error being __stack_chk_fail is undefined. Ubuntu's
> version of gcc enables stack check by default and adding
> -fno-stack-protector to CFLAGS did not help. I haven't figured this one
> out yet but Helloworld.efi builds correctly.
build with -fno-stack-protector ... at least that's where the problem is
coming from in my environment. I don't have an ubuntu system to check,
but to verify this is your issue, try:
nm -D /usr/lib/libefi.a | grep __stack_chk_fail
(or whatever your path is to libefi.a) ... probably you should also
check libgnuefi.a, although this one is clear in my setup.
James
Khalid Aziz
Jul 19, 2012, 11:55:47 AM7/19/12
to James Bottomley, joeyli, linux-...@vger.kernel.org, linu...@vger.kernel.org
On Thu, 2012-07-19 at 10:41 +0100, James Bottomley wrote:
> Actually, I just ran into this too. Apparently libefi.a needs to be
> build with -fno-stack-protector ... at least that's where the problem is
> coming from in my environment. I don't have an ubuntu system to check,
> but to verify this is your issue, try:
>
> nm -D /usr/lib/libefi.a | grep __stack_chk_fail
>
> (or whatever your path is to libefi.a) ... probably you should also
> check libgnuefi.a, although this one is clear in my setup.
On Ubuntu, it is coming from lib/lib.a. It so happens that "make clean"
> Actually, I just ran into this too. Apparently libefi.a needs to be
> build with -fno-stack-protector ... at least that's where the problem is
> coming from in my environment. I don't have an ubuntu system to check,
> but to verify this is your issue, try:
>
> nm -D /usr/lib/libefi.a | grep __stack_chk_fail
>
> (or whatever your path is to libefi.a) ... probably you should also
> check libgnuefi.a, although this one is clear in my setup.
does not descend into lib/ and remove *.o and lib.a. So, I added
"-fno-stack-protector" to top level Makefile, ran "make clean" followed
by make and it didn't help because I continuesd to use the old lib.a.
Now that I have realized it, I added "(cd lib; rm -f *.o lib.a)" to the
clean target in toplevel Makefile and ran a "make clean". After this
lib/Makefile inherited -fno-stack-protector in CFLAGS from Make.rules
and everything builds correctly now.
--
Khalid Aziz <khali...@hp.com>
0 new messages