FreeBSD and UEFI?

After running into problems installing FreeBSD on a box that has UEFI enabled I started reading about UEFI related to FreeBSD. I found these readers:

https://wiki.freebsd.org/UEFI

Having read this I wondered about
Glue UEFI boot logic into the distribution build. In progress

Then I started reading

http://bsd.slashdot.org/story/13/07...egins-work-on-booting-on-uefi-enabled-systems

and I began to realize, that it's about DRM and I started asking myself why I should trust Microsoft CA when installing FreeBSD? As trust has gone recently I decided to disable UEFI.

Your thoughts?

PS: Be prepared when users (not me!) owning a box with Windows8 x64 preinstalled begin asking, how to install FreeBSD and want multiboot. After all it looks like it is a battle.
 
You don't. Secure Boot has the Custom Mode (Microsoft requirement, by the way), where you can manage trusted keys.

Little more on how the UEFI Forum seeks for an another authority provider can be seen here for example.
 
Some basics of code signing:

  • The signer has a private key/public key -pair. The public key is often called a certificate.
  • The private key is used for signing files, the certificate is used to verify the authenticity of the signatures found in the signed files
  • Files signed with a certain private key will not verify with any other certificate than the one that matches the private key.

All put together it should be clear that the pre-installed Microsoft certificate in an UEFI BIOS is useless for verifying any other files that those that have been signed by Microsoft itself using their own private key. Talking about "trusting" Microsoft CA when the OS is a non-Microsoft is bogus because there is nothing to trust or not to trust, there is no way we can ever have a FreeBSD loader binary that is digitally signed by Microsoft.
 
Are you forced to use them? If you can install your own certificates then why use the shim loaders at all?
 
Does that mean that I can checkout projects/uefi branch and build the system from it in order to give UEFI a try?
 
The point of the FreeBSD UEFI Secure Booting is just so that FreeBSD can boot on UEFI machines with Secure Boot enabled by using the existing keys. In theory, FreeBSD could supply a custom key that the user would have to install. In practice, there appears to be no standard on how keys are installed, so this would be beyond the ability of many users, as would disabling Secure Boot.

The FreeBSD UEFI code should only be needed if you want to enable Secure Boot. Also, it won't work until there is a certificate.

Interestingly, the article mentioned above did not mention the fact that Windows 8 on ARM requires Secure Boot, and requires that it cannot be disabled: http://technet.microsoft.com/en-us/library/hh824987.aspx. If there has been some sort of justification for that, I haven't seen it.
 
wblock@ said:
The point of the FreeBSD UEFI Secure Booting is just so that FreeBSD can boot on UEFI machines with Secure Boot enabled by using the existing keys. In theory, FreeBSD could supply a custom key that the user would have to install. In practice, there appears to be no standard on how keys are installed, so this would be beyond the ability of many users, as would disabling Secure Boot.

The FreeBSD UEFI code should only be needed if you want to enable Secure Boot. Also, it won't work until there is a certificate.

Interestingly, the article mentioned above did not mention the fact that Windows 8 on ARM requires Secure Boot, and requires that it cannot be disabled: http://technet.microsoft.com/en-us/library/hh824987.aspx. If there has been some sort of justification for that, I haven't seen it.

I believe Microsoft wants to have their way with warranty, if secure boot is bypassed or otherwise tampered with they can claim that the warranty is void on the product.
 
Remember that UEFI boot does not imply secure boot. You still can boot in UEFI mode without a trusted key, but secure boot must be disabled.

Also, note that all option roms and firmwares which are loaded at boot, must be signed or at least UEFI compatible in order to enable secure boot, or take full advantage of UEFI boot. One of the most critical firmwares is the video system firmware, it must to be compatible with UEFI GOP. Integrated graphics on UEFi compatible motherboards are almost all compatible, but discrete graphic cards are adopting it slowly, so full UEFI boot and secure boot are not supported in most actual systems.
 
Every time I've tried to set up a GPT boot on this machine it always fails to boot, but it does work with the MBR method. So is it just a matter of UEFI not being supported yet?
 
UEFI and GPT have nothing much to do with each other. You can have a perfectly good working GPT boot with a plain old BIOS.
 
GPT was part of the UEFI specification. But GPT does not require UEFI.

There are buggy BIOS implementations that will not boot from GPT disks. Thinkpads had this problem, but later BIOS versions are supposed to fix it. So first, upgrade the BIOS.
 
zspider said:
Every time I've tried to set up a GPT boot on this machine it always fails to boot, but it does work with the MBR method. So is it just a matter of UEFI not being supported yet?

It is the fault of the BIOS! Is it a Dell? I have one Dell here (Inspiron N7110) which refuses to boot unless the BIOS sees a MBR scheme. It is a common problem not only on Dell machines but it is a misconception and not the rule.

I can confirm that GPT works fine with BIOS on my other machines and does not need UEFI.
 
Erratus said:
and I began to realize, that it's about DRM and I started asking myself why I should trust Microsoft CA when installing FreeBSD? As trust has gone recently I decided to disable UEFI.

Your thoughts?

Unless you don't dual boot Windows you can deactivate Secure Boot.
 
vanessa said:
It is the fault of the BIOS! Is it a Dell? I have one Dell here (Inspiron N7110) which refuses to boot unless the BIOS sees a MBR scheme. It is a common problem not only on Dell machines but it is a misconception and not the rule.

I can confirm that GPT works fine with BIOS on my other machines and does not need UEFI.

This particular machine is an ASUS KV55D actually, my BIOS is current as far as I know, so I guess GPT just isn't usable in this situation.
 
My BIOS is also latest (though one year old) and still refuses to boot from GPT because Dell simply doesn't care. Here they confirm the missing functionality:

The currently shipping in BIOS in Inspiron 7110 does not support this feature at this time. It may be added with a BIOS upgrade in the future.
 
vanessa said:
My BIOS is also latest (though one year old) and still refuses to boot from GPT because Dell simply doesn't care. Here they confirm the missing functionality:

If only they spent more time improving their existing hardware lineups than trying to ram new stuff through every couple of months. Maybe the AMI BIOS leak will someday make GPT work.

I have a Dell laptop that is 2.5 years old, it's falling apart, hard drive died, keys on the cheap keyboard are starting to pop off, never again. Their desktops seem to be good though, I have several that are quite old and still running including one going on 11 years and a motherboard someone pulled from an even older Dell computer in the garbage that is running my network.:e
 
vanessa said:
I can confirm that GPT works fine with BIOS on my other machines and does not need UEFI.

Same here on INTEL machines with latest firmware. GPT is fine with BIOS mode, UEFI does not work for GPT.

As long as there is no benefit UEFI is for me deprecated.
 
Well guys, the FULL story about my Dell is that the board is faulty so the BIOS can not save to CMOS, which means that I can't even change the boot device order! So the only way to boot from CD or USB is when the HDD fails to boot. So basically on the first install I had to physically get the disk out of the laptop, kill the MBR, install FreeBSD, then bring it back in.

Fortunately, I have now FreeBSD's boot0 on the MBR so it saves the day ;) Dell again? Never!
 
Erratus said:
Same here on INTEL machines with latest firmware. GPT is fine with BIOS mode, UEFI does not work for GPT.

This is strange - quite the opposite of the normal behaviour ...
 
Possibly related to a PMBR problem. If the PMBR is set active, very strict UEFI systems may refuse to boot from it. On the other hand, some BIOS versions may not boot from a PMBR that is not set active.
 
On INTEL DH67CL and INTEL D2500CC with latest firmware
# gpart create -s gpt ada0
# gpart add -t freebsd-boot -l gptboot -b 40 -s 512K ada0
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
# gpart add -t freebsd-zfs -l gptsys -b 1M -a 4k ada0

does not work with UEFI enabeled. It does work with UEFI disabeled, which I consider to be BIOS mode. These mainboards do not have UEFI Secure Booting.
 
Back
Top