What do you guys think about SecureBoot?

L

lockfile

I'm sure by now most people in Unix and Unix-like land have heard about SecureBoot subsystem that wishes to reside in EFI, and EFI along with SecureBoot is set to replace BIOS in the future.

Microsoft is going to be the arbiter of who gets to have a SecureBoot key, subsequently, deciding who can load an operating system on a computer system, and what operating system can be loaded onto a computer system.

Have you heard of the FreeBSD Foundation said anything on the matter as yet? And, what do you guys think about this SecureBoot mechanism, and what does this mean for the future of free Unix-like, and "Mr. Joe Penguin" who wants to make his own "free [beer and freedom] Unix-like" OS and put it on the computer system he bought with his own money?
 
Here is a nice article about the current state of another Open Source OS and Secure Boot.

There exist already an open source first stage bootloader called "Shim" that has been signed by Microsoft. Shim would start Grub 2, which allows to boot any other OS, including FreeBSD.

Since viable technical solutions exist already, I do think there is not so much left to worry about.

Especially, I do not think that Microsoft is using SecureBoot to prevent *BSD (or the other OSOS) from running on modern hardware. I think, that at the end of the day, also FreeBSD users would benefit from the additional security by the Shim/Grub 2 combo on UEFI hardware.
 
Yes that is good that Shim is a reality. But does it bother you or anybody else here that the entire industry (Redhat included) has to depend on Microsoft for the security of signing keys and have to petition Microsoft for more keys? What is so wrong with people signing their own keys or use BIOS like many customers in the industry truly want to do with their purchased hardware?

I was not informed of the voting process or get my chance to cast a ballot on which company gets to hold the SecureBoot keyring.

I am slightly upset.
 
I think it's awesome how this stuff works, with one exception:
People should be able to approve the certificates in their "BIOS". Say, FreeBSD wants to boot using UEFI Secure Boot, but not using a recognized certificate? Require user to approve the certificate.

Anyone trying to convince you that the user shouldn't be able to do this, is essentially saying the user shouldn't be allowed to decide what runs on their system. And that's bad. Because if you bought a computer, you own it. And as such, you should decide what can or cannot run on it. ><
 
1. I think I'll stick with RISC.
2. How much time will elapse before someone:
a. hacks SecureBoot,
b. comes up with an open source substitute?

The idea of being dependent upon a single company for something that may be completely closed/ proprietary doesn't exactly sound like an invitation to a fun party.
 
My understanding is that the secureboot stuff is only on PC's that are bought with windows included. If you build your own PC from parts then this isn't a problem is it? Also I thought they were only enforcing it on ARM hardware as well and not i386/amd64.
 
As far as I know it's not Microsoft that signs the certificates but some other entity. Anyone can get a certificate signed. All you need to do then is to add that certificate to UEFI and SecureBoot will work for whatever it was you signed.

I do believe that OEMs that manufacture complete PCs (with the OS on them) already did this with the Microsoft certificates. Which is why everybody thinks it's Microsoft that signs these things.
 
I believe it is a good idea.

We've had about 40 years of writing operating systems that are secure, and have failed - largely because users fail - they are easily subverted with trojan-like applications and other compromised software. Source code availability is not a silver bullet - most people can't read/write source, and plenty of those who CAN don't have the time to audit all the code for their system before they compile and run it.

Enforcing validation that the code you are running is actually as it was originally written and signed off on, from the vendor you think it is from is a step in the right direction - and the only way you can verify that your code signature checking facility has not been subverted is to set up code signing pre-operating system boot.

So long as the user can install their own keys (and they can) i have no problem with it what so ever, and look forward to the day where i can actually trust that the code i think i am running is actually legit.

Savagedlight said:
I think it's awesome how this stuff works, with one exception:
People should be able to approve the certificates in their "BIOS". Say, FreeBSD wants to boot using UEFI Secure Boot, but not using a recognized certificate? Require user to approve the certificate.
Click to expand...

On x86/x64 you can (the Windows RT on ARM devices are a dead end and don't). For security purposes I am guessing you need to drop back out of the OS and into the UEFI boot application to update the keys (having it writable from within the OS would be foolish - presumably this part of the UEFI is read-only via some sort of privilege demotion after the UEFI interface has terminated), but yes, that is the idea.

I know people tend to dislike apple and their "walled garden" but iOS is pretty free of malware for the most part due to the code signing requirement. Yes, if the code signing infrastructure is compromised you're still screwed, but it is a LOT less code to try to secure than an entire OS - and rely on heuristics in anti malware software to attempt to catch dodgy binaries.

With code signing - if the binary is trojaned, it won't match the signature the original developer signed it with, and therefore will warn/not run - whether or not you have an AV program or not.
 
throAU said:
With code signing - if the binary is trojaned, it won't match the signature the original developer signed it with, and therefore will warn/not run - whether or not you have an AV program or not.
Click to expand...
This is where we, FreeBSD users, are up the proverbial creek. If you recompile your kernel the signature won't match anymore. So for every new kernel (or update) you would need to get it signed.
 
SirDice said:
This is where we, FreeBSD users, are up the proverbial creek. If you recompile your kernel the signature won't match anymore. So for every new kernel (or update) you would need to get it signed.
Click to expand...

Wouldn't it be the boot loader rather than the kernel? In which case really all you need to do is make sure your recompiled boot loader is byte for byte the same as the one distributed with the FreeBSD releases. Although I guess as soon as someone updates the loader on -STABLE or -CURRENT you are screwed.

Actually, I assume it's not even the boot2 loader, and is actually just the loader that gets installed into the freebsd-boot partition of GPT using the gpart bootcode commands. This very rarely gets updated.

Or am I misunderstanding secureboot.
 
SecureBoot only works with UEFI as far as I know. UEFI requires a FAT partition from where it loads a "loader". You may be right though if that's the only bit that's actually signed.

I think I looked for some UEFI boot code for FreeBSD, if I'm not mistaken FreeBSD-ia64 has one as that's the only way to boot an IA-64 system. I did see some commits in -CURRENT that hinted at some work being done on getting the IA-64 EUFI boot to work on AMD64.
 
throAU said:
I believe it is a good idea.
So long as the user can install their own keys (and they can) i have no problem with it what so ever, and look forward to the day where i can actually trust that the code i think i am running is actually legit.
Click to expand...
I also belive it is a good idea, but sadly it will turn out to be broken by how it will be carried out.

As with ACPI, which is a good idea/approach IMHO, it is the incompetence of those who implement it that it mostly only works with whatever windows that is present. My crystal ball tells me this is what is goint to happen to the secure boot as well.

Just read that when you buy a machine with Win8-OEM preinstalled you cannot upgrade to the -pro version because the installer reads your activation key from the ROM and tells you your -pro key is invalid. So this seems already to have started.
I know people tend to dislike apple and their "walled garden" but iOS is pretty free of malware for the most part due to the code signing requirement. Yes, if the code signing infrastructure is compromised you're still screwed, but it is a LOT less code to try to secure than an entire OS - and rely on heuristics in anti malware software to attempt to catch dodgy binaries.

With code signing - if the binary is trojaned, it won't match the signature the original developer signed it with, and therefore will warn/not run - whether or not you have an AV program or not.
Click to expand...

Well, when (not if) the infrastructure is compromised, you are screwed way beyond the point you would if this was not a central infrastructure.

Another thing I would like to point out is that it is not sufficient to only secure all binaries but you need also to secure all scripts which call them and thus also anchor that chain of certificates at the other end; all the way to the init process and all the way to the last bit of code which calls back to the kernel.

xtaz said:
Wouldn't it be the boot loader rather than the kernel? In which case really all you need to do is make sure your recompiled boot loader is byte for byte the same as the one distributed with the FreeBSD releases. Although I guess as soon as someone updates the loader on -STABLE or -CURRENT you are screwed.
Click to expand...
The boot loader is signed and loaded by the UEFI, which has the certificate and can check if the loader is clean. Then the loader itself may contain other certificates and use them to check if the components it has loaded are also clean by it's standards. That will give you a loaded kernel which is considered untampered by the loader. The kernel then can also check if whatever file is going to memory is matching a certificate which may be part of the kernel or it may take one from the ROM or whatever.

Anyone notice that I wrote "loaded", not "executed"? What is executed may be something else (see race condition in PS3 hack), be stringed together by some exploit or by a script, ...

The secure boot will improve the security of the net, no question. It may rid us of a whole lot of zombie swarms. But it will not be the silver bullet, and it most certainly will have a huge impact on anything that is not in the prime interest of those who push it.
 
I believe Microsoft DOES sign the keys. What's getting mixed up is that Microsoft did not create secure boot but some other agency did but you still need to get the keys from Microsoft. Am I wrong?
 
AFAIK we also have the option of turning SecureBoot OFF and enabling Legacy Boot options if we don't have proper / signed bootloaders for other OS's.
 
drhowarddrfine said:
I believe Microsoft DOES sign the keys. What's getting mixed up is that Microsoft did not create secure boot but some other agency did but you still need to get the keys from Microsoft. Am I wrong?
Click to expand...

I do think that's wrong, but honestly have not really worried about it yet. There's a good chance it will be broken before it is even in wide use, or like DKIM, the bad guys will happily use it. Just because it's signed does not mean it's not a virus.

An exception is ARM tablets with Windows 8, where there is no way to disable it. If I bought one of those without knowing the situation, the vendor would hear from me. But since I know about it, the vanishingly small chance I would buy a Windows 8 ARM tablet has gone to zero.
 
Microsoft does not make computers so they are not in the position to dictate how the BIOS has to be configured for non-Microsoft OSes. End of story.
 
wblock@ said:
Just because it's signed does not mean it's not a virus.
Click to expand...
That is surely true. And that is one of my points, really.
With this will come some kind of I-am-invincible attitude, and then it will turn out to be not so.
An exception is ARM tablets with Windows 8, where there is no way to disable it. If I bought one of those without knowing the situation, the vendor would hear from me.
Click to expand...
Oh, those guys will shake in their boots - not. Sorry, but what do you expect them to do about that? You would not even get a refund. Been there, done that, threw away the free t-shirt. :(
All this might do is make some land shark (a.k.a. lawyers) rich, because without them you very rarely get anything back.

kpa said:
Microsoft does not make computers so they are not in the position to dictate how the BIOS has to be configured for non-Microsoft OSes. End of story.
Click to expand...
Microsoft may be in the position to allow for lower priced OEM versions to be preinstalled when certain, ahem, 'experience enhancements' are slipped into the BIOS. Start of problem.
 
kpa said:
Microsoft does not make computers so they are not in the position to dictate how the BIOS has to be configured for non-Microsoft OSes. End of story.
Click to expand...
They don't make computers, correct. But they do have certain demands if you want to sell computers with Windows pre-installed on them. Don't like the demands? Too bad, you won't get the license from Microsoft. So even though they don't make computers themselves they are certainly in a position to dictate how the BIOS/UEFI is configured.
 
The problem is multifold.

Microsoft is the one who has the certificates which are to be preinstalled and wants to be paid for each signing, hence the pre-boot loader which in turn then loads the real boot loader like grub. Otherwise each change to grub stage1 would require a new signing.

Even if the need for signed code loading by the UEFI can be disabled today, who knows if it will stay that way? In the tablets, they already demand that it is not to be switched off, that there even shall not be any switch at all. Given what we know of the quality of ACPI, I would not want to bet that equal problems will not creep up on general-purpose HW in time.

The standard may demand that the user be able to kill existing certificates and supply his own, but will this really work? And if it works today, will it be working tomorrow?

All this smells of TCPA and Paladium comming back from the place where we thought they were burried those years before.

I am looking both ways for this, sadly. On the one side I like the idea to stop tampering with core parts of the OS without problem, but then there are the ways to abuse this technology. And it will be abused, as any technology has been after it has been invented. In the end, it is all about trusting those with the keys.
 
I still don't understand the benefit to this...

If "we" the open-source community can just used a presigned shim bootloader for all our operating systems... could a committed virus writer not do the same?

Perhaps they use the open-source signed shim to boot their dodgy platform which then in turn boots Windows and does nasty things to the user. Are we not back in exactly the same boat?

There has got to be more to this game plan of Microsoft's in the grand scheme of things because it certainly doesn't seem to be protecting the user.
 
SecureBoot is nothing more then a Microsoft cry on deathbed vigil to try to be monopolist and to make people life a PITA, a run for money, there is nothing about technology in it.
 
Yea I don't like it either. Many on the traditional nerd forums (Slashdot, OS News...) say that SecureBoot is a tax on Unix-like OSes and MS indeed does hold the ring that controls SecureBoot.

SecureBoot: do not want.
 
Except for Flight Simulator and perhaps the X-Box (disclaimer: I hardly have any experience with the latter) I honestly cannot think of anything even remotely decent Microsoft have come up with since MS-DOS and that was way back in the days when DOS was still sort of ok.

So now Microsoft is going to provide all of us with security? I don't think so.

Fonz
 
$MS$ (item 23) symbolizes the failure of the development of computer. That people do not settle for monopolies is necessary to prevent further additions to that wheel of capitalism (Damn wheel, should remain square). Go ahead, we can laugh from his bugs... at same time hate our bugs
devilgrin.gif


PS Our concern fix our own mistakes, their concern make more money selling their mistakes or bought pieces of code mistakes.

A piece of cake:
Judge Jackson issued his findings of fact on November 5, 1999, which stated that Microsoft's dominance of the x86 based personal computer operating systems market constituted a monopoly, and that Microsoft had taken actions to crush threats to that monopoly, including Apple, Java, Netscape, Lotus Notes, RealNetworks, Linux, and others. Judgment was split in two parts. On April 3, 2000, he issued his conclusions of law, according to which Microsoft had committed monopolization, attempted monopolization, and tying in violation of Sections 1 and 2 of the Sherman Act. Microsoft immediately appealed the decision. On 2000-06-07, the court orders a breakup of Microsoft as its remedy. According to that judgment, Microsoft would have to be broken into two separate units, one to produce the operating system, and one to produce other software components.
Click to expand...

UEFI Secure Boot will smell a new possible lawsuit...
 
You must log in or register to reply here.
Back
Top