PfSense 2.3 UEFI boot support?
-
I'm curious to know if pfSense intends to support UEFI boot support, etc with 2.3? I don't have a spare rig I can test with, but from my understanding with FreeBSD 10.3-R, it's become fairly stable.
I'm considering nuking/paving my home router to clean up from the 2.2.6 -> 2.3 upgrade, and would like to use UEFI if it's supported.
Assuming pfSense supports it (as I thought I'd seen the boot support in the image), is this a configuration ESF is able to support now? or should I wait a few more releases?
Thanks
-
As far as I know there are only two tangible benefits of UEFI over BIOS and neither of those are of particular importance to any host using pfSense. Hard drive partitions larger than 2TB and more than four partitions on a drive. The other claims of speed and reliability are only as good as the UEFI implementation, hardware compatibility and the OS being booted.
-
Not supported at this time.
-
haha, i just spent an hour trying to get pfSense installed on a UEFI enabled server. I finally gave up and this just happens to be the first post I see on the board. Why didn't I come here first?
-
From a security standpoint we should stick with true and tried BIOS instead of UEFI.
UEFI looks pretty cool but it also makes it easy to load hacked code in it. BIOS is very limited and pretty much locked down to keep itself from being modified by malware.
-
As far as I know there are only two tangible benefits of UEFI over BIOS and neither of those are of particular importance to any host using pfSense. Hard drive partitions larger than 2TB and more than four partitions on a drive. The other claims of speed and reliability are only as good as the UEFI implementation, hardware compatibility and the OS being booted.
NVMe boot?
-
NVMe boot?
Agreed. UEFI would be needed to boot NVMe drive, but why would anyone think it absolutely necessary for a pfSense box to boot from NVMe SSD in 2016 when there are plenty of other cheaper and supported SSD devices available? We are talking about booting a firewall, not some read/write intensive application.
I think that BIOS code will be updated in new motherboards to allow recognition of NVMe devices. I suppose it all depends on how important the SSD manufacturers and BIOS publishers consider catering for legacy applications. It appears at the moment that AHCI and NVMe M.2 devices are sold as distinctly separate devices but I don't think they have to be.
I don't have any NVMe devices and I'm unlikely to for some time. I do remember a long time ago when 16-bit operating systems were popular and hard disk storage outgrew what was available in the BIOS tables of most machines. Certain tricks were used by replacement boot managers to map the larger drives over existing drives in the hard coded BIOS tables for a few years until IDE arrived. Perhaps something similar will be incorporated into a modern BIOS itself, the ability to recognise the first 2TB of a NVMe SSD for booting under ATA/SATA/AHCI emulation then transferring to OS driver for native NVMe support when the OS has started.
-
Secure Boot.
KNOWING that unapproved code can't boot your firewall is a good thing.
It's a pity that FreeBSD is badly dragging feet on the idea.But at least feet dragging is better than the OpenBSD response of "It's Microsoft, so it must be bad and we hates it, we hates it for ever".
-
NVMe boot?
Agreed. UEFI would be needed to boot NVMe drive, but why would anyone think it absolutely necessary for a pfSense box to boot from NVMe SSD in 2016 when there are plenty of other cheaper and supported SSD devices available? We are talking about booting a firewall, not some intensive read/write intensive application.
I think that BIOS code will be updated in new motherboards to allow recognition of NVMe devices. I suppose it all depends on how important the SSD manufacturers and BIOS publishers consider catering for legacy applications. It appears at the moment that AHCI and NVMe M.2 devices are sold as distinctly separate devices but I don't think they have to be.
I don't have any NVMe devices and I'm unlikely to for some time. I do remember a long time ago when 16-bit operating systems were popular and hard disk storage outgrew what was available in the BIOS tables of most machines. Certain tricks were used by replacement boot managers to map the larger drives over existing drives in the hard coded BIOS tables for a few years until IDE arrived. Perhaps something similar will be incorporated into a modern BIOS itself, the ability to recognise the first 2TB of a NVMe SSD for booting under ATA/SATA/AHCI emulation then transferring to OS driver for native NVMe support when the OS has started.
Samsung M.2 EVO 250GB is about $6 more expensive than the SATA, and it's much lower profile. You should see these things in real life, they're crazy small. My wife has an 850 PRO 512GiB. The pro is crazy fast, about 2.2GiB/s reads and a 5 year warranty. There's not many options right now, but give it about 1 years, we'll see a lot of these.
-
Samsung M.2 EVO 250GB is about $6 more expensive than the SATA, and it's much lower profile. You should see these things in real life, they're crazy small. My wife has an 850 PRO 512GiB. The pro is crazy fast, about 2.2GiB/s reads and a 5 year warranty. There's not many options right now, but give it about 1 years, we'll see a lot of these.
They are still more expensive in Europe. I guess manufacturers have to dump their older-tech products somewhere. £56 for 240GB SSD, £70 for 250GB M.2
I am sure that you are right about the speed of adoption. This time next year, M.2 will probably be the most popular form for solid state storage. If the storage manufacturers don't make the devices dual stack NVMe/AHCI, I hope that some PCIe card manufacturer implements an AHCI storage container card that can have multiple M.2 boards fitted. I suspect that UEFI is going to be a painful experience for many. It is already possible to brick some UEFI machines with systemd on Linux https://github.com/systemd/systemd/issues/2402
-
Secure Boot.
KNOWING that unapproved code can't boot your firewall is a good thing.
It's a pity that FreeBSD is badly dragging feet on the idea.UEFI Secure Boot is not the only way to do it.
In FreeBSD you can use BIOS, Trousers and TrustedGRUB2 with a TPM equipped board to sign not just the OS kernel but any file, file system or drive. In my opinion it's a far better way to achieve the same goal and you can do it now without having to rely on anyone else for signing.
-
Secure Boot.
KNOWING that unapproved code can't boot your firewall is a good thing.
It's a pity that FreeBSD is badly dragging feet on the idea.UEFI Secure Boot is not the only way to do it.
In FreeBSD you can use BIOS, Trousers and TrustedGRUB2 with a TPM equipped board to sign not just the OS kernel but any file, file system or drive. In my opinion it's a far better way to achieve the same goal and you can do it now without having to rely on anyone else for signing.
How can you verify any digital signatures on the first stage bootloader if you're booting using BIOS? Of course you can verify the signature at later stage in boot but that's not a complete chain of trust anymore.
-
@kpa:
How can you verify any digital signatures on the first stage bootloader if you're booting using BIOS? Of course you can verify the signature at later stage in boot but that's not a complete chain of trust anymore.
I don't think that there is a complete chain of trust with UEFI secure boot either. UEFI just delegates the responsibility for the chain of trust to one or more third parties that are not forced to prove that they are actually trustworthy all of the time.
I believe that a well founded chain of trust can only begin with a publicly scrutinised non reprogrammable ROM containing executable code that is the first code to execute upon reset and checks itself with the TPM before executing BIOS/UEFI. The only way this could ever be done with any certainty of trustworthyness is if there is:
-
International standardisation for a trusted boot process.
-
Boot code to be free and open source globally with published versioning
-
Code maintained by the United Nations Security Council only.
-
New code releases require a United Nations Security Council resolution.
-
Tampering with the code or subversion of the code is considered an act of war ( This needs a very special FOSS license ).
-
Published In byte code for the CPU architecture that can be translated to assembler by a FOSS companion tool.
This might sound over the top, but it is probably the only way to deter state funded intrusions.
An interesting paper that covers in reasonable detail the problem with x86 chain of trust today.
http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf -
-
UEFI exists and works in 2.4. Snapshots available soon.
-
@cmb:
UEFI exists and works in 2.4. Snapshots available soon.
CMB that is fantastic news! I am just now setting up a new esxi server and i wanted to use UEFI instead of bios for a fresh pfsense install and i was wondering when the snapshot will be available as currently today (21st July) snapshots.pfsense.org shows only version 2.3.2. Could you tell me how long it will be before there is a snapshot version that supports UEFI to download or could you provide a x64 download link so i can get it now?
Thank you for all your efforts in getting uefi support included! -
I worry that much of the network stack is now accessible to the EFI console. How do you trust the firmware is not siphoning off packets?
I think from a security standpoint it is not good.
Secure Boot Hardy har har.
Beware of trojans bearing gifts. -
I think when ADI-Netgate chose to use SeaBIOS on thier products it was a great pick. When I first got my SG2220 Ii was disappointed by the minimal BIOS but really what do you need a bios to do? Pick a boot drive. That is it. And that is what SeaBIOS does. Works well.
I realize PXE already has interaction with the BIOS but a network stack in the BIOS. Think about that.
-
At least with Coreboot-SeaBIOS it is all open souce. You can see exactly what the BIOS is doing.
I would call that Secure Boot. -
Here is a good comparison. SeaBIOS is not missing much I need.
https://en.wikipedia.org/wiki/BIOS#COMPARISON -
I'm slightly off topic with this, but UEFI boot usually implies a GPT format. Some modern larger hard disks have a 4K block size and my web research suggests that they should be formatted with partitions based on a 4K boundary and not the 63 sector / track formatting. Failure to do this can result in read-modify-write when writing to disk. With PFSense this can be achieved by formatting before install, also keeping the "old" partition table, but I found the PFSense installer is unhappy unless the partition starts on a multiple of 63 sectors. As a result I've formatted with the partition start as a multiple of 63 sectors AND a multiple of 4K block size - requiring a few minuites with a calculator. ( When doing the install do not then accept the option to format the disk, and select the pre-formatted partition / slice. ) More information with " Advanced format drives" in a search engine.
I hope nobody tells me I'm way off beam with the above.
What I'm leading to is, can an update also fix the installer so that it uses a more recent format routine than cylinder / head / sectors and either the inbuilt auto-install can be used - or - a pre-formatted (sliced) disk can be used with the first partition starting at 4096 or a number not divisible by 63? And a GPT partition table.