Recent Features
| |||||||||||||
No signed kernel, just a signed boot loaderNo signed kernel, just a signed boot loaderPosted Jun 22, 2012 18:47 UTC (Fri) by mjw (subscriber, #16740)Parent article: Details on Ubuntu's UEFI secure boot plan
We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed. Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules.So that is a lot more flexible than the Fedora approach. What is the reason Fedora will lock down the kernel and modules that access hardware directly? Is there a catch? Otherwise it seems it would be enough to just have one boot loader signed and with that people are free to install any kernel they want.
(Log in to post comments)
No signed kernel, just a signed boot loader Posted Jun 22, 2012 18:54 UTC (Fri) by cjb (guest, #40354) [Link]
mjg59's blog posts suggested that Ubuntu's approach would result in a key revocation, since the signed bootloader can be used to boot a kernel that installs Windows malware, defeating the security of the system.
No signed kernel, just a signed boot loader Posted Jun 22, 2012 19:54 UTC (Fri) by dashesy (subscriber, #74652) [Link]
I am no expert in this, but can the boot loader hide/protect the entire Windows partition so that kernel cannot access it, nor detect it's presence?
No signed kernel, just a signed boot loader Posted Jun 22, 2012 20:04 UTC (Fri) by cjb (guest, #40354) [Link]
> I am no expert in this, but can the boot loader hide/protect the entire Windows partition so that kernel cannot access it, nor detect it's presence?
No, not with current technology. Linux can simply undo whatever the bootloader does.
With eMMC devices, there's a "power-on read-only" lock that makes the device read-only until the next time the MMC controller loses power. If that technology were included in hard disks, something like you describe might be possible.
The eMMC power-on read-only technique was used on the T-Mobile G2 cell phone, stopping rooting of the device by making the kernel and rootfs read only inside the bootloader, before booting the kernel. It didn't hold out against sustained effort -- someone found a GPIO that the eMMC reset line was hooked up to, wrote a kernel module that pulses the line and reinits the MMC host in read/write mode before the VFS notices that anything changed, and disables the lock. Security is hard.
No signed kernel, just a signed boot loader Posted Jun 22, 2012 20:53 UTC (Fri) by marcH (subscriber, #57642) [Link]
http://www.schneier.com/blog/archives/2007/12/how_to_secu...
Computer security is hard. Software, computer and network security are all ongoing battles between attacker and defender. And in many cases the attacker has an inherent advantage: He only has to find one network flaw, while the defender has to find and fix every flaw.
Cryptography is an exception,...
No signed kernel, just a signed boot loader Posted Jun 25, 2012 7:56 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] Cryptography is an exception,...
That reminded me of this great chart Valerie Aurora once posted. Granted, that covers cryptographic hashes specifically, but I'd go so far as to suggest even cryptography is an arms race to some extent. Of course, practically, it's usually many orders of magnitude easier to attack the system around the cryptography than the cipher itself. (When it's not, it's because some genius decided to roll their own cipher, or someone installed a back door.) A 256-bit AES key is theoretically secure beyond the heat-death of the universe, provided nobody finds a mathematical weakness in AES. But, if you can find a flaw in the key generation, an attack against the AES implementation, or some other flaw in the hardware, software or communication stack it's employed in, then you transform the problem back into a software/computer/network security problem and your point stands. So don't mind me... I'm just being a little glib. Happens when I'm working overnight again. ;-)
No signed kernel, just a signed boot loader Posted Jun 23, 2012 14:37 UTC (Sat) by salimma (subscriber, #34460) [Link]
Seems to me that that wouldn't be fine-grained enough to make one partition read only while other partitions remain read/write.
No signed kernel, just a signed boot loader Posted Jun 23, 2012 15:06 UTC (Sat) by joey (subscriber, #328) [Link]
Signing a kernel does not prevent exploiting future security holes in the kernel. So in time there will be many signed kernels that can be used to install Windows malware.
No signed kernel, just a signed boot loader Posted Jun 24, 2012 16:54 UTC (Sun) by droundy (subscriber, #4559) [Link]
Besides that, couldn't a malware author simply run their windows-corrupting programs as root?
No signed kernel, just a signed boot loader Posted Jun 24, 2012 17:33 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
No. If they directly alter the Windows bootloader or kernel then booting Windows will fail. If they alter Windows userspace then the malware checking code that's started before any other userspace will notice.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:00 UTC (Mon) by dashesy (subscriber, #74652) [Link] If they alter Windows userspace then the malware checking code that's started before any other userspace will notice.Sure it should not be hard to fool malware checking code to believe that nothing is tinkered with, otherwise we already could have perfect anti-malware but we do not. If Windows user space program can be changed, Windows registry hives would be the target. Registry among other things controls many aspects of the NT kernel and some drivers, and maybe the secureboot itself BTW, I am not sure if Microsoft can afford denying its superusers from changing registry because in the practical world one most likely will need it
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Sure, anti-malware isn't perfect but if the system is thoroughly owned before the anti-malware starts and lies to it then you don't even have a chance. At least you have a small base system that's likely to be intact you can defend from before malware has a chance to subvert the system.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 22:47 UTC (Mon) by dashesy (subscriber, #74652) [Link]
True, but if secure boot relies on some sort of access controls or file protection (applied by NT kernel) any root access to the file-system can be used to circumvent the integrity of the entire system. OS kernel alone is not interesting. Malware can for example add its root certificate and set a startup service to install a driver on the next boot, there are probably some more creative ways to achieve the same thing.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
No it can't. Device drivers (and other critical system code) have to be signed.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:22 UTC (Mon) by dashesy (subscriber, #74652) [Link] I am assuming Malware is running under a legitimate Linux kernel (with no bugs) messing with Windows partition with full access right. So something like DISABLE_INTEGRITY_CHECKS in boot.ini no longer works on Windows 8? Also root can no longer use CertMgr to add custom certificate for custom signed drivers?My point is that, with the complexity of NT, by having root access to those bits and bytes the attack surface is so tremendous there is probably no need to have an unsigned Linux kernel
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:27 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>I am assuming Malware is running under a legitimate Linux kernel (with no bugs) messing with Windows partition with full access right. So something like DISABLE_INTEGRITY_CHECKS in boot.ini no longer works on Windows 8? Also root can no longer use CertMgr to add custom certificate for custom signed drivers?
Nope. Neither DDISABLE_INTEGRITY_CHECKS nor installing your own certificates will work if secure boot is enabled.
Drivers have to be signed by MS's certificate to be installable.
>My point is that, with the complexity of NT, by having root access to those bits and bytes the attack surface is so tremendous there is probably no need to have an unsigned Linux kernel
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:27 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
DISABLE_INTEGRITY_CHECKS no longer works unless you disable secure boot. Ditto any custom certificates.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 6:45 UTC (Tue) by slashdot (guest, #22014) [Link]
How about just installing a Windows service or putting something in the Startup folder or CurrentVersion\Run or /etc/init or .config/autostart in Linux, etc.?
Will anything prevent that software from starting and then going full screen and imitating the normal Windows GUI while behaving arbitrarily at the discretion of the malware writer?
If they block any autostart of non-Microsoft-signed programs, they'll break a ton of existing setups, while otherwise secure boot will provide no security whatsoever.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 13:29 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Windows starts the malware checking code before it launches any other userspace.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:12 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Yes, so it's a good thing that secure boot doesn't rely on that. Really, commenting on this without at least skimming the spec does not further the discussion.
No signed kernel, just a signed boot loader Posted Jun 24, 2012 17:33 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
And those will have their signatures revoked.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 3:46 UTC (Mon) by hummassa (subscriber, #307) [Link]
I would like to understand why and how. Why would an exploit over a Linux kernel punching thru an exploit over a Windows kernel would cause revocation of the signature of that kernel. I would also like to know HOW will they keep revocation databases for each and every hundreds of thousands exploitable Linux and Windows kernels -- and more, HOW they will catalog each of these exploitable kernels, if many of the exploits are as of this date still unknown by the white hats. And don't even get me started in two things:
1. cryptographic flaws can be exploited in the signing algorithms (like Flame virus) and cause the wrong (but unknown) kernel or bootloader to load; 2. a single flaw in the infrastructure used to revoke signatures can dismantle the whole card castle and cause a MASSIVE DoS... like "brick every windows8-capable computer ever".
Someone else in this thread mentioned that security is harder for the defender than for the attacker because the defender has to plug every hole, but the attacker need only to find one hole. I would add: the defender has to plug every hole AND still be able inside the system. Yes, if you add 10-feet-thick concrete walls around your house without doors or windows, no burglar will ever enter it... neither will you.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 4:10 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.
So that's the why - breaking the trust barrier results in revocation. The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.
And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 12:28 UTC (Mon) by hummassa (subscriber, #307) [Link]
There are a lot of problems in this.
> The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.
> So that's the why - breaking the trust barrier results in revocation.
That is the first problem with secure boot: KNOWINGLY breaking the trust barrier results in revocation. Worse yet: breaking the trust barrier knowingly and from the point of view of anyone in the trust chain results in revokation. This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".
Those two problems amount to: if someone in a high position in the "trust chain" can lock you out of your own computer because "fsck you, that's why", they can. More: they cannot lock malware out of your computer because (1) it is difficult/impossible to know what is malware after all and (2) lots of malware will stay hidden and the vulnerabilities that lead to infection and pnwing will not generate key revocations because people in the trust chain do not know about them. Again, stuxnet and flame are good example of "hidden for about two years", which is plenty of time for doing plenty of sabotage and espionage.
And then the problems in the how:
> The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.
It does not scale at all.
I have stated above that the why is a flawed premise. But the how is a nightmare. For someone to revoke a key what you have to do is to write that key or that sha256 or whatever to a database that will be read in the UEFI level. THAT, per se, is a huge vulnerability. Who writes that database? How is that database read (and checked for veracity) by the UEFI level? When? At boot time via the network (spoofable)? Read from disk (corruptible)? Signed? With the same key you are revoking? With an escrow key that can be used to revoke any key? You load a new key how? If all keys are revoked, what happens?
Basically, in security terms, you are revoking access to the computer for someone based on an externally-entered (coming from the network, no less!) string. This is as tainted as it gets.
But it only gets worse: the platforms (Linux/Windows8) and their kernels are not security proven and are not even security-oriented. They present lots of opportunities for attacks and they will continue doing so for a long time. It is virtually impossible to plug every single hole in them and it's impossible to revoke the key that signs them at every single vulnerability because if you do that (1) your revoked keys database will be huge and (2) you will force updates down the throats of the users, effectively locking them out of their computers, not forgetting (3) opening up new opportunities to attacks coming from the infrastructure outside the trust chain.
> And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.
The problem is, I am not even factoring implementation flaws, above. Just normal vulnerabilities (buffer overflows, integer overflows, finite state unexpected transitions, etc) and normal attacks OUTSIDE the "chain of trust" implementations (key distribution for reloading and revoking, etc).
And we still have to factor in cryptographic security failures that are sometimes exploitable (hash/signature collisions were used in Flame IIRC)...
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:43 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
If only the revocation mechanisms were documented in some kind of specification, or something. Wouldn't that be wonderful?
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:48 UTC (Mon) by hummassa (subscriber, #307) [Link]
linky linky?
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:51 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
No signed kernel, just a signed boot loader Posted Jun 26, 2012 1:49 UTC (Tue) by hummassa (subscriber, #307) [Link]
I had got it just before I saw your link; thanks. I will read it carefully in the next day or so (if $DAYJOB and $HOMECARE give me some space) and will get back to you. But I will tell you beforehand that if the mechanisms are not crowded with possible attack vectors I will be VERY pleasantly surprised.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 15:49 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".
This is BS because the owner can create their own keys, disable secure boot, etc. so they can't be shut out of their machine against their will, that is not a real thing. Now if you start talking about boot locked machines that might be a different story but we definitely are not talking about that, even MS wants to make sure x86 hosts aren't boot locked (only their ARM tablets, like many Android devices).
In any event this is a feature that can be used for the good of the system by the system owner and that is what Linux will use it for.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 18:10 UTC (Tue) by rahvin (subscriber, #16953) [Link]
The only reason MS changed (yes changed) the spec to allow disabling secure boot was because of public outcry. As others have pointed out this was one of the bullet points in the halloween memo (leveraging hardware alliances to lock out linux). It would be foolish to dismiss this potential motivation as MS sees Android as a significant threat.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 11:55 UTC (Mon) by micka (subscriber, #38720) [Link]
I'd be surprised if those who then broke my computer (ie those who revoked the key that allows it to boot) were not liable for that.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 15:12 UTC (Mon) by pboddie (subscriber, #50784) [Link]
I wonder how this marvellously "clever" scheme interacts with consumer rights legislation when people find that their laptops don't work any more because someone has pushed the remote off-switch.
Obviously, the whole thing is yet another competition-busting scheme with just enough spin to confuse the regulators and make neutral observers give it the benefit of the doubt (that it is "probably good for security" or the laughable claim that "Microsoft isn't running this show"), but these things usually meet their demise when people end up being sold "faulty" products.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 16:49 UTC (Mon) by micka (subscriber, #38720) [Link]
I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).
Of course, what applies to common people may not apply to Microsoft or Canonical.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:01 UTC (Mon) by gioele (subscriber, #61675) [Link]
> I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).
I suppose that there are a lot of other things that must happen at the same time before you jail someone. Otherwise every borked update to Debian sid or Rawhide would send quite a bit of people in prison.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:26 UTC (Mon) by pboddie (subscriber, #50784) [Link]
I think there's a difference between a "best effort" update - one that the users may actually have instigated themselves - and someone bricking those users' computers because they're running something that the people with the control don't like. Moreover, if a Debian or Fedora update went wrong, you could probably do a re-install - the hardware would still function in most cases - whereas "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run. And even then, at least for the average user, maybe it also involves the penalty of having to return the hardware for servicing.
But as I noted, such schemes are mostly used to erode the rights of users in the name of something else so that people don't question such schemes until after they have been introduced, and thus any argument about how a dominant vendor has managed to obliterate the competition can be waved away many years after the fact with excuses like "it's what the market expected" and "nobody demanded anything else".
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:39 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run
That is hyperbole and is not what secure boot on x86 does. It'd be great if we could stick to a discussion based on the facts.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:28 UTC (Mon) by pboddie (subscriber, #50784) [Link]
Oh sure, you can sign your own payloads and install your own keys, but in practical terms this means that people who buy computers will not only have to put up with what the vendor pre-installed - just like the majority of people won't ever "install Linux over Windows", even though lots of people think that this is a good enough workaround - but they will have yet another barrier if they do ever discover that they could run something else.
And I'm sure it's not beyond the skills of the vendors to make installing one's own keys a near impossibility and then claiming it was an accident for as long as it takes before they can then claim that the product is no longer supported.
So in practical terms, it is all about control. We can discuss technical workarounds as much as we like and deny that the technology imposes any particular restrictions, but the combination of one company's continuous strategy of pushing the regulatory envelope and that technology results in a shoring up of that company's position.
Why else are the distributions jumping through hoops? Because they like a challenge? The practical effect of the misuse of such a technology is as much a fact as any aspect of the "it's OK - I can still boot my kernel" technical discussion.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> you can sign your own payloads and install your own keys
So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 11:03 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Oh well, let this be another place on the Internet I have to go back to at some point in the future and write "I told you so" for all the good that actually does. Nothing to see here, I guess: keep staring at the bits and bytes.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 18:10 UTC (Tue) by marcH (subscriber, #57642) [Link]
> > you can sign your own payloads and install your own keys
> So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.
Too bad things are not that obvious to Fedora and Canonical. They should have hired you and saved a lot of effort.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 19:14 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Oh har har har, Mr Sarcastic guy. In any event I am merely relating the understanding and rationale that Fedora and Canonical have publicly written. The fact that the OP doesn't seem to want to read or understand that is the issue I'm trying to correct.
Foolish on my part I suppose. http://xkcd.com/386/
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:56 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
The core issue here is the on-by-default requirement for consumer hardware coupled with the specs limitations which prevents a mult-vendor trust chain.
Secureboot as a concept is not a bad thing. The policy surrounding how to enable secureboot for consumer devices needs some iteration however. There is absolutely nothing wrong with an off-by-default secureboot even with the current specification and limitations. On-by-default, has some definite challenges, and MS's certification process requirements brings these challenged directly into the forefront of the discussion.
Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem. As long as users are not locked out of the firmware config screens to disable secureboot on the hardware they purchased, a 3rd party revocation process is best described as a very stringent notification about a potential system compromise. If users can disable secureboot they do not lose access to their systems even after a key that their current configuration requires has been revoked.
In fact I'd wager that once the security benefit is digested more widely large institutions like the US Department of Defense and the State Department and even municipal power companies will be making heavy use of secureboot with their own signing keys on a lot of critical infrastructure and even desktops and laptops...so they don't even have to implicitly trust any Vendor (including Microsoft). They'll use the firmware reconfiguration to the fullest to load their own keys on their hardware and then self-sign binaries and to control the revocation process from end-to-end.
-jef
No signed kernel, just a signed boot loader Posted Jun 25, 2012 19:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> specs limitations which prevents a mult-vendor trust chain
I'm not sure that's true, you can have many vendor and user keys loaded into the firmware but to get your key pre-loaded would require some relationship with the vendor so your hardware coverage is likely to be less than 100%, whereas all the vendors want to be able to run MS so that key is virtually guaranteed to be loaded by default.
Actual binaries can be signed by only one key though so to boot and reduce the number of boot media spins required forces you to choose which key you are going to use to sign your initial boot loader and the MS key wins on convenience there.
> Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem
Which is exactly the case now for x86. Win8 ARM hosts are boot locked but that's its own separate issue at this time, I don't think any Linux vendor is going to fool around with them. Just don't buy them an expect to run anything else on them (not much different that the rest of the ARM market anyway).
> companies will be making heavy use of secureboot with their own signing keys
Thats probably something they will want to do but it depends on how to sign or re-sign boot binaries. Is it possible to re-sign the Windows 8 boot loader for example and have the system not broken? Certainly this will be do-able, maybe even common, with Linux systems.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 7:27 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
You seem to have a lot of faith in municipal power companies commitment to security...
Unfortunately, regardless of the "should", there are plenty of examples to the contrary.
Whatever the original intent, in reality, UEFI's largest impact so far has been to impose a significant cost on open-source software, with the to-be-determined security benefits still vaporware..
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:33 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
so why aren't the sony execs in prison for their PS/3 update that made it impossible to run linux or other OSs?
No signed kernel, just a signed boot loader Posted Jun 26, 2012 7:41 UTC (Tue) by micka (subscriber, #38720) [Link]
Citing myself :
> Of course, what applies to common people may not apply to Microsoft or Canonical.
or Sony. The "Microsoft or Canonical" was not meant to be exhaustive.
Of course I'm exagerating. Even the individual cracker that bricks _one_ computer would not go to jail... t1he first time, unless they go against a police or big corporate computer.
The second time would be very different, though.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:09 UTC (Mon) by JEFFREY (subscriber, #79095) [Link]
Precisely, my concern regards a sort of mass DOS attack where someone evil has obtained the keys and remotely disables 90% of the computers out there. Oops.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:15 UTC (Mon) by raven667 (subscriber, #5198) [Link]
My guess is that the risk is about the same someone breaking into the major vendors and pushing out an update that wipes everyones hard drives, ie. not very likely at all.
|
|||||||||||||