# FreeBSD and UEFI?



## Erratus (Oct 2, 2013)

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.


----------



## ondra_knezour (Oct 2, 2013)

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.


----------



## kpa (Oct 2, 2013)

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.


----------



## ondra_knezour (Oct 2, 2013)

@kpa: Not true, Microsoft signs submited shim loaders, which can be used to load another OS, see https://wiki.freebsd.org/SecureBoot


----------



## kpa (Oct 2, 2013)

Are you forced to use them? If you can install your own certificates then why use the shim loaders at all?


----------



## ondra_knezour (Oct 2, 2013)

No, but it may provide easier way for some "technically impaired" users


----------



## hedgehog (Oct 3, 2013)

Does that mean that I can checkout projects/uefi branch and build the system from it in order to give UEFI a try?


----------



## wblock@ (Oct 3, 2013)

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.


----------



## kpa (Oct 3, 2013)

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.


----------



## ColdfireMC (Oct 8, 2013)

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.


----------



## zspider (Oct 8, 2013)

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?


----------



## SirDice (Oct 8, 2013)

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.


----------



## wblock@ (Oct 8, 2013)

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.


----------



## vanessa (Oct 8, 2013)

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.


----------



## vanessa (Oct 8, 2013)

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.


----------



## zspider (Oct 9, 2013)

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.


----------



## vanessa (Oct 9, 2013)

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


----------



## zspider (Oct 9, 2013)

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


----------



## Erratus (Oct 9, 2013)

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.


----------



## vanessa (Oct 9, 2013)

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!


----------



## vanessa (Oct 9, 2013)

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


----------



## wblock@ (Oct 9, 2013)

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.


----------



## Erratus (Oct 9, 2013)

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.


----------



## wblock@ (Oct 9, 2013)

But what version of FreeBSD was that?  The new PMBR was only merged back to 9-STABLE on August 29: http://svnweb.freebsd.org/base/stable/?view=log&pathrev=255017


----------



## Erratus (Oct 9, 2013)

wblock@ said:
			
		

> but what version of freebsd was that?  The new pmbr was only merged back to 9-stable on august 29: http://svnweb.freebsd.org/base/stable/?view=log&pathrev=255017


9.2-RELEASE has required it to disable UEFI.


----------



## sossego (Oct 9, 2013)

This has been discussed on the mailing list: http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045032.html


----------



## Erratus (Oct 9, 2013)

> On 03/10/2013, at 7:46 AM, Michael Copeland <michael at kryptos-security.com> wrote:
> 
> > Hmm
> > Should I build with GCC?
> ...


With the Microsoft reference we are back on the reason, this thread was started. I'm happy without UEFI. In fact I took the opportunity to install Windows 7 back on MBR. Works fine here and no BIOS manual switching is required.
Recent Windows versions are known, that they do not wait until the user mounts a hot plugged removable disk device. It not only tries to get information from that device, but even tries to write on it. Therefore I feel much more secure if Windows does not touch/search/index my removable FreeBSD disks at all.


----------



## wblock@ (Oct 9, 2013)

Erratus said:
			
		

> 9.2-RELEASE has required it to disable UEFI.



I don't understand what you mean by that.


----------



## Erratus (Oct 10, 2013)

A FreeBSD 9.2-RELEASE installation with GPT, did not boot when UEFI was enabeled. It was required to disable UEFI in order to have any use oft it.


----------



## wblock@ (Oct 10, 2013)

Ah, but that's not necessarily due to FreeBSD 9.2.  Clearing the active flag on the PMBR may make it work: `gpart clear -a active ada0`


----------



## Erratus (Oct 10, 2013)

wblock@ said:
			
		

> Ah, but that's not necessarily due to FreeBSD 9.2.  Clearing the active flag on the PMBR may make it work: `gpart clear -a active ada0`



Your command is some sort of pseudo code that could be understood by humans but not by the gpart() tool, which has implemented

`gpart set -a attrib -i index [-f flags] geom`
`gpart unset -a attrib -i index [-f flags] geom`

gpart clear is not known by gpart.

Activating is a term used in the MBR environment. As far as I understand GPT schemes there is no such thing. At least with GPT scheme it is different.

In gptboot() can be read:


> PARTITION ATTRIBUTES
> gptboot checks and manages several attributes of GPT UFS partitions.
> 
> _bootme_	 Attempt to boot from this partition.  If more than one partition has the bootme attribute set, gptboot will attempt to boot each one until successful.
> ...



So ada0p1 should not have any attributes by default and it has none, as can been seen:


```
#> gpart list ada0
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 488397134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 524288 (512k)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: d100e823-2e89-11e3-9ba8-e069956961c1
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: gptboot
   length: 524288
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 1063
```

Your turn


----------



## kpa (Oct 10, 2013)

The problems is that the GEOM provider that represents the GPT partitioned disk hides the protective MBR and all the partition table entries in it so it's not possible to edit the protective MBR or it's properties directly while the GEOM class instance that handles the GPT partitioned disk has a lock on the disk. You can possibly use the old fdisk(8) to edit the PMBR but it would have to be done in single user mode or from a rescue media.


----------



## Erratus (Oct 10, 2013)

You mean change the *flag 80* to zero?

fdisk() allows only to set the flag to a partition


```
#> fdisk -a /dev/ada0p1
******* Working on device /dev/ada0p1 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=16 sectors/track=63 (1008 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=1 heads=16 sectors/track=63 (1008 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 945 (0 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 0/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
Partition 1 is marked active
Do you want to change the active partition? [n] y
Supply a decimal value for "active partition" [1] 0
Active partition number must be in range 1-4.  Try again.
```


----------



## kpa (Oct 10, 2013)

No, don't use it on the ada0p1 partition but on the whole disk ada0. The partition type should be 


```
sysid 238 (0xee),(EFI GPT)
```
.

I'm wondering however if the FreeBSD fdisk(8) actually allows the clearing of the active flag alltogether. Linux fdisk does I'm pretty sure so you could try some Linux live CD.


----------



## SirDice (Oct 10, 2013)

Erratus said:
			
		

> You mean change the *flag 80* to zero?
> 
> fdisk() allows only to set the flag to a partition


Correct. I ran into this myself some time ago. I had to manually 'unset' that flag to get my system booting again.

Thread 35897


----------



## Erratus (Oct 10, 2013)

I found this tool which might do the job: sysutils/gdisk
And an informative site on this theme: http://www.rodsbooks.com/gdisk/hybrid.html

Here is a first dry run: 


```
#> gdisk /dev/ada0
GPT fdisk (gdisk) version 0.8.6

NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk's partition table!
You may be able to enable writes by exiting this program, typing
'sysctl kern.geom.debugflags=16' at a shell prompt, and re-running this
program.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Recovery/transformation command (? for help): o

Disk size is 488397168 sectors (232.9 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1           39   primary     0xEE
   2                    40         1063   primary     0xA5
   3                  2048    488397127   primary     0xA5

Command (? for help): r

Recovery/transformation command (? for help): h

WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 1 2
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): [red]y [/red]

Creating entry for GPT partition #1 (MBR partition #2)
Enter an MBR hex code (default A5):
Set the bootable flag? (Y/N): [red]n[/red]

Creating entry for GPT partition #2 (MBR partition #3)
Enter an MBR hex code (default A5):
Set the bootable flag? (Y/N): [red]n[/red]

Unused partition space(s) found. Use one to protect more partitions? (Y/N): [red]n[/red]

Recovery/transformation command (? for help): q
```

As Iâ€™m still uncertain if I choose the right options and still thinking about possible side effects like this: 





> Note that even with the extra protective partition, significant parts of a disk could go unprotected. In the case of this example, it's just a few sectors at the end of the disk; however, if you hybridize two non-contiguous partitions, the last of which is not at the end of the disk, either the partitions at the end of the disk or the space between the partitions will be unallocated in an MBR sense.


comments are welcome.


----------



## wblock@ (Oct 10, 2013)

Sorry, I cut a sample from email that was wrong.  But it was close, should have been `gpart unset -a active ada0`.  You will need a recent 9-STABLE to be able to use that.

Don't use hybrid MBRs, that combines the worst features and problems of both.

Edit: finally fixed, not "clear" but "unset".


----------



## Erratus (Oct 10, 2013)

wblock@ said:
			
		

> Sorry, I cut a sample from email that was wrong.  But it was close, should have been `gpart clear -a active ada0`.  You will need a recent 9-STABLE to be able to use that.
> 
> Don't use hybrid MBRs, that combines the worst features and problems of both.



I do not see any difference to post 30. Did you edit it?
So `gpart clear` is not implemented in 9.2-RELEASE.

Manually editing the raw device should also be possible, but how?


----------



## zspider (Oct 10, 2013)

I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?


----------



## Erratus (Oct 10, 2013)

zspider said:
			
		

> I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?



USB uses just it's own interface. If I remember it right, what I've learned in the past days, booting from USB is like booting from BIOS legacy. So you should check your BIOS setup regarding UEFI, when using the "main" interface (i.e. ad*).


----------



## zspider (Oct 10, 2013)

Erratus said:
			
		

> USB uses just it's own interface. If I remember it right, what I've learned in the past days, booting from USB is like booting from BIOS legacy. So you should check your BIOS setup regarding UEFI, when using the "main" interface (i.e. ad*).



UEFI can't be disabled on this version of the AMI BIOS, it used to be you could, but they took that option away judging by screenshots of menus past. Thanks for the tip about the USB, I'm glad I didn't tear down a working system just to see if it would work.


----------



## Erratus (Oct 10, 2013)

So you updated your BIOS and lost disabling UEFI? Then I would look at the release notes of the BIOS versions of your mainboard and look if you can load an legacy BIOS version, that does not affect problems you might have had.
Some people update without any need their BIOSes, just for having a newer one. This is generally not advisable to do, unless you have a problem on the system you have to solve.


----------



## wblock@ (Oct 10, 2013)

Erratus said:
			
		

> I do not see any difference to post 30. Did you edit it?
> So `gpart clear` is not implemented in 9.2-RELEASE.



No, it should be "unset".  Edited now



> Manually editing the raw device should also be possible, but how?



Read the PMBR into a file, modify, then write it back out.  But that requires knowledge of the construction of the PMBR.


----------



## vanessa (Oct 11, 2013)

zspider said:
			
		

> I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?



Interesting ... Was it your BIOS handing over to the USB drive or was it the boot0 loader on the HDD?


----------



## zspider (Oct 11, 2013)

vanessa said:
			
		

> Interesting ... Was it your BIOS handing over to the USB drive or was it the boot0 loader on the HDD?



I have different hostnames for each install, so when it booted I was able to tell immediately that it indeed booted from the external drive.



			
				Erratus said:
			
		

> So you updated your BIOS and lost disabling UEFI? Then I would look at the release notes of the BIOS versions of your mainboard and look if you can load an legacy BIOS version, that does not affect problems you might have had.
> Some people update without any need their BIOSes, just for having a newer one. This is generally not advisable to do, unless you have a problem on the system you have to solve.



Actually ironically I think the reason I updated it (quite a while ago) was to see if I could get that option, going back isn't really a good idea, especially when many of the updates involve "thermal protection" or "thermal policies". I'm fine with the MBR way as long as the sectors can be 4k aligned and as far as I can tell, they are.


----------

