SecureBoot -- still not supported??

N

neutrino78x

Hi,

So I've been using FreeBSD since the 90s...I turn 40 next month...anyway, I saw articles from as far back as 2014 saying that FreeBSD was going to support SecureBoot...but now the SecureBoot page on FreeBSD.org says it is still not supported. Is that really the case?

I have a machine with SecureBoot, but it can be disabled. I'm tempted to disable it just for FreeBSD.

Anyway what's the status? :)
 
Why don't you try to boot the newest FreeBSD release off a usb stick and find out for yourself?
Other people might be interested in / care for the SecureBoot support in FreeBSD, or they might not.
The only way to be sure is to test it yourself.
 
My guess is always that Secure Boot was first introduced to prevent users from installing anything but Windows and Windows Drivers upon a closed-source bloated ROM, the UEFI, whose developement is, in my opinion, ultimately carried out under Microsoft financement. If it weren't for possible issues with Intel Vt-d (mostly rumors I heard though), I had replaced my UEFI with coreboot+Seabios already.

Anyway, that's the staus of SecureBoot support, as of 09/18/17: https://wiki.freebsd.org/SecureBoot :)
 
Actually, all secure boot is, is that every piece of software that is used to start the machine is digitally signed. So you would sign the FreeBSD EFI Bootloader, loader, and the kernel. You can even use your own certificate to do it, generated via SSL. Furthermore, you need to add the keys to your PC's BIOS to recognize it as being valid.

Windows certified hardware only has Microsoft's keys installed in the UEFI BIOS, but that doesn't mean that you can't add more.

Further Reading:
http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot (Specifically for Linux, but good info)
https://wiki.freebsd.org/SecureBoot (FreeBSD Wiki which has some decent links as well.)

HTH
 
maelstrom wrote:

Further Reading:
http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot (Specifically for Linux, but good info)
Click to expand...

This is actually a fascinating article dude! Thank you for showing me that. :)

My only objection to the procedure it discusses is, how would one boot to Windows after doing that? The procedure appears to involve deleting all the signatures and then adding your own custom ones. It appears that this would render your PC unable to boot Windows (unable to boot Windows while SecureBoot is enabled, anyway). Is there a way to sign the Windows boot binary? Is there a way to extract the signature of the Windows binary and add it to your custom list of approved signatures?

Looks like Sensucht94 confirms that FreeBSD still doesn't have a SecureBoot signature yet. So I go back to my original question...Why is that? Did somebody just give up on that project?

I dunno...SecureBoot seems like a good idea in theory. But they didn't make it easy for us to add approved signatures without deleting all the existing ones. Desktop PCs got by just fine without SecureBoot for 30+ years, I suppose there's no harm in disabling it so I could boot FreeBSD on this machine. :)

But the Linux distributions can use the Linux signature and boot with SecureBoot...couldn't FreeBSD register one with Microsoft so FreeBSD could also boot under SecureBoot along with Windows and Linux? :)
 
This past fall (2017) semester at Sac State, I attended a security seminar where the topic was secure boot. The person who gave the lecture is Tim Lewis, CTO of Insyde Software. They provide the BIOSes for a lot of the laptop manufacturers. It was an interesting lecture to say the least. Anyways, the BIOS chip has a file system on it. So you shouldn't have to delete everything there just to be able to dual boot Windows and FreeBSD/Linux. You could make a backup and add the certificate to the backup and then write it back into the BIOS. But, each BIOS and mainboard is different, so I don't really have an answer for you.

But going back to the original articles that I posted, I think the reason why FreeBSD doesn't have it is because (if you know how) it is relatively trivial to digitally sign the boot loader and kernel.

I don't know how to do it off the top of my head, but Windows does allow you to digitally sign files on the system. On Windows 10, the system checks the digital signatures of the installation packages and puts that info on the screen before you click OK. You can even extract the digital signature from the files in question.

EDIT:

Perhaps the developers can add to make buildkernel a make.conf(5) option to sign the bootloader and kernel with a specified certificate. That way, it would sign the bootloader and kernel everytime you build the kernel. The developers could also submit the public code signing certificate to the mainboard manufacturers so they can include it on the BIOS in the default configuration. I do not know why this hasn't been done yet...but it wouldn't be hard to do.
 
If the FreeBSD source code contained the certificate that allows generating a signed bootloader/kernel, and ...

If anyone can modify the FreeBSD source code (because the source is freely available, after all), and ...

If BIOSes on motherboards (or laptops) have been taught the signature of the FreeBSD kernel and are willing to believe that it is secure and therefore boot it, then ...

Any hacker could create any destructive piece of software they want, put it in a customer FreeBSD kernel, sign it, and distribute, and computers would boot it thinking it is a harmless FreeBSD kernel.

Thereby reducing the idea of FreeBSD being able to securely booted ad absurdum. Or is my reasoning faulty?

The whole concept of "secure" anything requires trust. Trust requires a trust authority. Who do you want to be the authority for FreeBSD? The secure way of doing this would be to give the certificate only to Kirk McKusick (*), and after he blesses the kernel, he can sign it. (* Footnote: I'm using Kirk as an arbitrary example of an authority here, any other human or group of humans who are reliable and worthy could substitute.)
 
Your logic is flawless, and you make a good point. That's why I suggested that the administrator sign the kernel themselves with their own private certificate during the build process. I wish there was a way to install multiple certs in the bios without having to erase all of them before hand.
 
ralphbsz said:
Thereby reducing the idea of FreeBSD being able to securely booted ad absurdum. Or is my reasoning faulty?

The whole concept of "secure" anything requires trust. Trust requires a trust authority. Who do you want to be the authority for FreeBSD? The secure way of doing this would be to give the certificate only to Kirk McKusick (*), and after he blesses the kernel, he can sign it. (* Footnote: I'm using Kirk as an arbitrary example of an authority here, any other human or group of humans who are reliable and worthy could substitute.)
Click to expand...
I wonder why one thinking seriously about security would even consider scenario other than that. I prefer to trust silicon and firmware (especially with coreboot instead of IntelME) than software bootloader anyone with physical access can replace. Best use case I would expect from secure OS FreeBSD claims to be would as follows:
- insert PKCS#11 token during installation - you can use cheap Yubikey with yubico-piv or if you don't trust they hardware your own FOSS one synthetized on FPGA with SymbiFlow
- FreeBSD initialize X.509 cert or use existing one to populate to UEFI keys as the only root of trust
- FreeBSD assists user anytime signing bootloader/kernel/modules is required

I'm Linux user, considering FreeBSD but this seems like a blocker for me. It there any "bugzilla" to divide and conquest some development challenges ? Because you don't need to develop everything at once - like Linux distro did - you can start with "shim" - signed bootloader but with default trust and then develop in parallel userspace tools and bootloader/kernel verification.
 
By looking at the wiki you could try the method described in the second link

FreeBSD UEFI Secure Boot | FreeBSD Foundation

1. Introduction Secure boot provides a way to ensure that only authorized EFI binaries are loaded by a computer's firmware. This ensures that no malicious code can run before the operating system is loaded. This document describes one method of securing FreeBSD's boot process. FreeBSD's regular...
freebsdfoundation.org freebsdfoundation.org
This instruction come from https://github.com/ZakSN/FreeBSD-UEFI-secure-boot
which is 3 years old so it is not really new
 
The truth is that Secure Boot is a "WIP". It's not a high-priority project, since all mainstream hardware lets you disable it and the sad reality is convenience beats security for most.

Disclaimer: I work at Microsoft, but not on Windows or UEFI.
 
neel said:
The truth is that Secure Boot is a "WIP". It's not a high-priority project, since all mainstream hardware lets you disable it and the sad reality is convenience beats security for most.
Click to expand...

The fact that Secure Boot pretty much needs to be disabled to get a useful operating system on the machine shows that it is fairly broken by design. I feel it unfortunately also got in the way of a more correct security technology being developed.

And seeing all those Windows RT ARM tablets going to landfill because of an artificially restrictive Secure Boot is in my opinion, a criminal act.

Do experts honestly feel that i.e Linux distros getting a "signed shim" from Microsoft was the correct approach? Bizarre. It makes me wonder what other things they are also getting completely wrong.
 
drhowarddrfine said:
It's still your fault by association.
Click to expand...
LOL.

The reality is that my team is under the Exchange umbrella. I don't work on Exchange, but on an adjacent team (Workplace Analytics) working on C# backend code. Ironically, my personal domain runs Postfix/Dovecot on FreeBSD, but this setup predated my employment and I have reasons not to switch over.

If UEFI breaks FreeBSD, I can't help you. If I were to transfer to Windows I probably will have to leave you all behind, provided I can even get in. Not to mention I don't want to transfer to Windows for other reasons as well, for instance, the Windows "Made Man" culture is a turn-off (in comparison my current team has been excellent) even if I gave up FreeBSD completely.

The most I can do is write FreeBSD patches to unbreak us. I have a few patches committed for hardware support, but I don't have access to the Windows code for reference (nor is it ethical), so the reference would be Linux. And I'm not really a kernel programmer, I'm more of a Ports person, but I do have occasional kernel patches here and there.
 
kpedersen said:
The fact that Secure Boot pretty much needs to be disabled to get a useful operating system on the machine shows that it is fairly broken by design. I feel it unfortunately also got in the way of a more correct security technology being developed.

And seeing all those Windows RT ARM tablets going to landfill because of an artificially restrictive Secure Boot is in my opinion, a criminal act.

Do experts honestly feel that i.e Linux distros getting a "signed shim" from Microsoft was the correct approach? Bizarre. It makes me wonder what other things they are also getting completely wrong.
Click to expand...
The truth is Windows RT tablets are long EOL, so someone could just write an exploit to force Secure Boot off.

People did this on many Android devices and even iPhones.

Even if you could disable Secure Boot, doesn't mean Linux/BSD will run out of the box. You'll have to port it. And unlike say Apple Silicon Macs, there's no compelling advantage of a Windows RT device over an x86 PC.

Current Windows ARM devices may allow you to disable Secure Boot, and Apple Silicon Macs allow you to enroll custom keys (but the latter doesn't use UEFI).

I work at Microsoft, I do think these devices should let you disable Secure Boot, but I'm not in Windows and Windows RT's death was wayyy before my employment. Like in the above post, I don't want to transfer to Windows.
 
neel said:
The truth is Windows RT tablets are long EOL, so someone could just write an exploit to force Secure Boot off.
Click to expand...
My main workhorse is a 2005 ThinkPad. Much older than the RT tablets. I don't really subscribe to the idea that technology can ever reach EOL unless it no longer can be fixed. Even then, it is up to the individual owners to make that judgement call. There were a number of jail breaks involving holding the volume up key but the damage was already done by this point.

neel said:
Even if you could disable Secure Boot, doesn't mean Linux/BSD will run out of the box. You'll have to port it. And unlike say Apple Silicon Macs, there's no compelling advantage of a Windows RT device over an x86 PC.
Click to expand...
Things like locked down Secure Boot reduces the passion of potential developers to port something. If a hardware is sound, usually a talented developer can make an initial port within a fortnight!

Annoyingly the RT hardware isn't bad. It is thin, light, fairly solid and has great battery. My only issue with it is that it is artificially crippled by Microsoft. That is a shame!

Obviously not getting on to you or anything. Also Microsoft are not even the worst for this. The whole hardware industry is a mess at the moment.
 
Windows RT devices were crippled anyways (not a good thing). Forget about even Ubuntu, you can't even run Chrome or Photoshop, making it useless for 99.9% of users. We've seen how Huawei got crippled without Google Apps, even if they have great hardware, but unlike Huawei, Microsoft had an option to sell fully-functional devices. Windows 8 could have begun Windows-on-ARM years earlier and maybe the PC world could have owned ARM laptops instead of Apple.

Today's Windows-on-ARM is less crippled, you can run x86 Windows apps and disable UEFI Secure Boot. You can even run Ubuntu on one in place of Windows. In short, they're ARM64 computers with a normal UEFI and the ability to run Chrome and Photoshop, although with slow x86 emulation.

Apple went further by making emulated x86 faster than the real thing, not only matching but beating Intel. Windows/Linux/*BSD should also do this.
 
Is the Secure Boot project on hold due to a lack of funding? How much would it cost to see it through if someone were to ballpark it? And, is it possible to just direct funds to that specific project directly?
 
You must log in or register to reply here.
Back
Top