iPXE discussion forum

Full Version: UEFI SecureBoot support
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'd like to ask regarding this ipxe-devel mailing post from Michael Brown, if there is any chance to get the undionly.efi signed.

I was trying to find something new about that but no luck..

I have unfortunately constrain, not allowing me te disable the stupid secure boot (I really didn't found until now good reason for it unless MS makes some $$ with it.)

Thanks a lot for any info.
(2014-11-11 22:10)mijanek Wrote: [ -> ]I'd like to ask regarding this ipxe-devel mailing post from Michael Brown, if there is any chance to get the undionly.efi signed.

I was trying to find something new about that but no luck..

I have unfortunately constrain, not allowing me te disable the stupid secure boot (I really didn't found until now good reason for it unless MS makes some $$ with it.)

UEFI code signing now requires an EV code-signing certificate, which I don't currently have. The certificate costs US$500 (for three years). The submission process is tedious and slow, but workable.

It's likely to happen as soon as someone thinks it's worth more than US$500 to get a SecureBoot-signed version of iPXE. By default, UEFI does not apply SecureBoot checks to binaries present in NIC ROMs, which reduces the utility of having a signed version of iPXE; it's only chainloading that would really benefit.

Michael
(2014-11-12 14:37)mcb30 Wrote: [ -> ]
(2014-11-11 22:10)mijanek Wrote: [ -> ]I'd like to ask regarding this ipxe-devel mailing post from Michael Brown, if there is any chance to get the undionly.efi signed.

I was trying to find something new about that but no luck..

I have unfortunately constrain, not allowing me te disable the stupid secure boot (I really didn't found until now good reason for it unless MS makes some $$ with it.)

UEFI code signing now requires an EV code-signing certificate, which I don't currently have. The certificate costs US$500 (for three years). The submission process is tedious and slow, but workable.

It's likely to happen as soon as someone thinks it's worth more than US$500 to get a SecureBoot-signed version of iPXE. By default, UEFI does not apply SecureBoot checks to binaries present in NIC ROMs, which reduces the utility of having a signed version of iPXE; it's only chainloading that would really benefit.

Michael

OK, thanks a lot. I know the constrains with the EV certificate (and know, that Verisign wan'ts 700$ per year for it).
Do you know however it would even pass the certification process at all?

And how is about the wimboot, does this need to be signed then too, or is it something like binary plugin to ipxe? (Microsoft says they sign only .efi files)

(Unfortunatelly I can't access NIC ROM, as I need this for the Tablets e.g. Surface 3 Pro with USB network card, so no chance here. )
(2014-11-12 18:39)mijanek Wrote: [ -> ]OK, thanks a lot. I know the constrains with the EV certificate (and know, that Verisign wan'ts 700$ per year for it).

Actually, US$500 for three years if you know where to look. Smile

Quote:Do you know however it would even pass the certification process at all?

I have previously obtained SecureBoot signed binaries, so yes.

Quote:And how is about the wimboot, does this need to be signed then too, or is it something like binary plugin to ipxe? (Microsoft says they sign only .efi files)

wimboot would also need to be signed. The wimboot executable is an EFI executable (even though it doesn't have a .efi suffix).

Michael
Michael, thanks a lot.

I'll see if someone in our company would be free to pay/proceed this.

P.S. I love the http download possibility, in my test compared to tftp on MS Surface 3 Pro it takes about 20 sec to boot up the winpe against 5 minutes using tftp..
Hi,

I would like to try the uefi chainloading binary undionly.efi.

Is there chances to make it public like undionly.kpxe and post it on the website ?
Hello everybody,

what a pitty
so we can’t use ipxe if we have uefi with secure boot on.
All Systems that are shipped with Windows 8 have this
option enabled and I don’t have the authority to disable this
function.

ipxe works in uefi mode really quick and fast.

When i boot winpe over tftp in legacy mode without ipxe it
takes 20 seconds to boot. When i boot winpe with bootx64.efi in uefi mode over tftp without ipxe it takes 4,5 minutes.
Secure boot on worked here, but it's to slow.
Does anybody know why the performance is so slow. The transfer rate
from our server is 1,1 MB/s.

It doesn't matter which hardware we use. It's always slow
@mijanek

pxe->bootx64.efi (from windows install dvd)->bcd (pointing to winload.efi)->boot.wim

I have found a solution to decrease the boot time from 5 minutes to 8 seconds. that's amazing.
you can increase the ramdisktftpblocksize in the BCD file. So the clients load faster.
see the following url for description
https://technet.microsoft.com/en-us/libr...px#BKMK_11

the following command does the trick
bcdedit /store c:\yourpathtobcd\bcd /set {INSERT_RAMDISK_GUID} ramdisktftpblocksize 65536
Microsoft recommend not to increase the value higher than 16384
I used a value of 65536 without problems.

The good point is that you can enable secure boot in this scenario Wink
@kyor thanks for this hint. I will check it how it does behave in our environment. My intention to use iPXE is to replace buggy implementation of boot server discovery in UEFI BIOS (No manufacturer is working as expected in UEFI, it seems that they start to implement it on Intel's example which isn't appropriate) I have currently open issue @Lenovo, they are now working on a solution.
I have only tested it mainly on many asus mainboards and
Intel NUC systems and aopen mini barebone systems
On these Plattform it works fine
Sometimes the value of 65000 is to high. In this case the system loads very
Slow.
I have set the value down
I just tested it on Lenovo Thinkpad T10 and with 65536 it refuses to boot at all (boot manager didn't start to load) with 32768 it started to download and was very quick but stuck at about 40%. With the Microsoft recommended maximum of 16384 is is still very fast and it booted up smoothly, so I will try wit this, to see how it behave on network loads
Unfortunately VMWare NetFX3 emulated adapter works only with max 4096 :-(

This explains a lot:
http://www.bctechnet.com/vmware-pxe-limitations/
Reference URL's