All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: UEFI Secure boot using qemu-kvm
@ 2012-06-28 10:01 joeyli
  2012-06-28 10:22 ` James Bottomley
       [not found] ` <CAGLnvc-hLpUZaaOkeWMRtYefwL5goxuWP_99FyAzem7s_mncPg@mail.gmail.com>
  0 siblings, 2 replies; 15+ messages in thread
From: joeyli @ 2012-06-28 10:01 UTC (permalink / raw)
  To: JBottomley; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-28 10:01 UEFI Secure boot using qemu-kvm joeyli
@ 2012-06-28 10:22 ` James Bottomley
  2012-06-28 10:49   ` joeyli
       [not found] ` <CAGLnvc-hLpUZaaOkeWMRtYefwL5goxuWP_99FyAzem7s_mncPg@mail.gmail.com>
  1 sibling, 1 reply; 15+ messages in thread
From: James Bottomley @ 2012-06-28 10:22 UTC (permalink / raw)
  To: joeyli, JBottomley; +Cc: linux-kernel



joeyli <jlee@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. 

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Fwd: UEFI Secure boot using qemu-kvm
       [not found] ` <CAGLnvc-hLpUZaaOkeWMRtYefwL5goxuWP_99FyAzem7s_mncPg@mail.gmail.com>
@ 2012-06-28 10:24   ` joeyli
  2012-06-30 16:21     ` joeyli
  0 siblings, 1 reply; 15+ messages in thread
From: joeyli @ 2012-06-28 10:24 UTC (permalink / raw)
  To: JBottomley; +Cc: linux-kernel

Hi James, 

於 四,2012-06-28 於 18:11 +0800,lee joey 提到:
> 
> 
> ---------- Forwarded message ----------
> From: joeyli <jlee@suse.com>
> Date: 2012/6/28
> Subject: Re: UEFI Secure boot using qemu-kvm
> To: JBottomley@parallels.com
> Cc: linux-kernel@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?
> 

I just found this issue only happen on when I used ssh connect to the
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.


Thanks a lot!
Joey Lee



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-28 10:22 ` James Bottomley
@ 2012-06-28 10:49   ` joeyli
  0 siblings, 0 replies; 15+ messages in thread
From: joeyli @ 2012-06-28 10:49 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-kernel

於 四,2012-06-28 於 11:22 +0100,James Bottomley 提到:
> 
> joeyli <jlee@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. 
> 
> 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

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 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Fwd: UEFI Secure boot using qemu-kvm
  2012-06-28 10:24   ` Fwd: " joeyli
@ 2012-06-30 16:21     ` joeyli
  2012-07-12 22:17       ` Khalid Aziz
  0 siblings, 1 reply; 15+ messages in thread
From: joeyli @ 2012-06-30 16:21 UTC (permalink / raw)
  To: linux-kernel; +Cc: JBottomley

於 四,2012-06-28 於 18:24 +0800,joeyli 提到:
> Hi James, 
> 
> 於 四,2012-06-28 於 18:11 +0800,lee joey 提到:
> > 
> > 
> > ---------- Forwarded message ----------
> > From: joeyli <jlee@suse.com>
> > Date: 2012/6/28
> > Subject: Re: UEFI Secure boot using qemu-kvm
> > To: JBottomley@parallels.com
> > Cc: linux-kernel@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?
> > 
> 
> I just found this issue only happen on when I used ssh connect to the
> 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.
> 
> 
> Thanks a lot!
> Joey Lee
> 

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Fwd: UEFI Secure boot using qemu-kvm
  2012-06-30 16:21     ` joeyli
@ 2012-07-12 22:17       ` Khalid Aziz
  2012-07-19  9:41         ` James Bottomley
  0 siblings, 1 reply; 15+ messages in thread
From: Khalid Aziz @ 2012-07-12 22:17 UTC (permalink / raw)
  To: joeyli; +Cc: linux-kernel, JBottomley, linux-efi

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 <khalid.aziz@hp.com>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Fwd: UEFI Secure boot using qemu-kvm
  2012-07-12 22:17       ` Khalid Aziz
@ 2012-07-19  9:41         ` James Bottomley
  2012-07-19 15:55           ` Khalid Aziz
  0 siblings, 1 reply; 15+ messages in thread
From: James Bottomley @ 2012-07-19  9:41 UTC (permalink / raw)
  To: Khalid Aziz; +Cc: joeyli, linux-kernel, linux-efi

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








^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Fwd: UEFI Secure boot using qemu-kvm
  2012-07-19  9:41         ` James Bottomley
@ 2012-07-19 15:55           ` Khalid Aziz
  0 siblings, 0 replies; 15+ messages in thread
From: Khalid Aziz @ 2012-07-19 15:55 UTC (permalink / raw)
  To: James Bottomley; +Cc: joeyli, linux-kernel, linux-efi

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"
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 <khalid.aziz@hp.com>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 20:01         ` Matthew Garrett
@ 2012-06-28 18:36           ` Alex Elsayed
  0 siblings, 0 replies; 15+ messages in thread
From: Alex Elsayed @ 2012-06-28 18:36 UTC (permalink / raw)
  To: linux-kernel

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 
dropped some implicit #includes AIUI.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 19:53       ` James Bottomley
@ 2012-06-27 20:01         ` Matthew Garrett
  2012-06-28 18:36           ` Alex Elsayed
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Garrett @ 2012-06-27 20:01 UTC (permalink / raw)
  To: James Bottomley; +Cc: 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 
not for you.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 19:38     ` Matthew Garrett
@ 2012-06-27 19:53       ` James Bottomley
  2012-06-27 20:01         ` Matthew Garrett
  0 siblings, 1 reply; 15+ messages in thread
From: James Bottomley @ 2012-06-27 19:53 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: 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
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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 19:35   ` James Bottomley
@ 2012-06-27 19:38     ` Matthew Garrett
  2012-06-27 19:53       ` James Bottomley
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Garrett @ 2012-06-27 19:38 UTC (permalink / raw)
  To: James Bottomley; +Cc: 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?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 18:15 ` Matthew Garrett
@ 2012-06-27 19:35   ` James Bottomley
  2012-06-27 19:38     ` Matthew Garrett
  0 siblings, 1 reply; 15+ messages in thread
From: James Bottomley @ 2012-06-27 19:35 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: linux-kernel, Jonathan Corbet

On Wed, 2012-06-27 at 19:15 +0100, Matthew Garrett wrote:
> 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 
> 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).
> 
> It's probably worth noting that booting unsigned kernels violates the 
> 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.

I've tried to build pesign, but I have huge problems with the make
process; how did you build it?

However, sbsign (with four extra patches I've sent to Jeremy) seems to
be built and working.

James



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: UEFI Secure boot using qemu-kvm
  2012-06-27 17:34 James Bottomley
@ 2012-06-27 18:15 ` Matthew Garrett
  2012-06-27 19:35   ` James Bottomley
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Garrett @ 2012-06-27 18:15 UTC (permalink / raw)
  To: James Bottomley; +Cc: 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 
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).

It's probably worth noting that booting unsigned kernels violates the 
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 | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* UEFI Secure boot using qemu-kvm
@ 2012-06-27 17:34 James Bottomley
  2012-06-27 18:15 ` Matthew Garrett
  0 siblings, 1 reply; 15+ messages in thread
From: James Bottomley @ 2012-06-27 17:34 UTC (permalink / raw)
  To: linux-kernel; +Cc: 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2012-07-19 15:55 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-28 10:01 UEFI Secure boot using qemu-kvm joeyli
2012-06-28 10:22 ` James Bottomley
2012-06-28 10:49   ` joeyli
     [not found] ` <CAGLnvc-hLpUZaaOkeWMRtYefwL5goxuWP_99FyAzem7s_mncPg@mail.gmail.com>
2012-06-28 10:24   ` Fwd: " joeyli
2012-06-30 16:21     ` joeyli
2012-07-12 22:17       ` Khalid Aziz
2012-07-19  9:41         ` James Bottomley
2012-07-19 15:55           ` Khalid Aziz
  -- strict thread matches above, loose matches on Subject: below --
2012-06-27 17:34 James Bottomley
2012-06-27 18:15 ` Matthew Garrett
2012-06-27 19:35   ` James Bottomley
2012-06-27 19:38     ` Matthew Garrett
2012-06-27 19:53       ` James Bottomley
2012-06-27 20:01         ` Matthew Garrett
2012-06-28 18:36           ` Alex Elsayed

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.