User: Password:
|
|
Subscribe / Log in / New account

Implementing UEFI Secure Boot in Fedora

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 13:24 UTC (Thu) by sblack (guest, #81076)
Parent article: Implementing UEFI Secure Boot in Fedora

I got the overwhelming impression from Matthew Garrett's talk[1] (title, "EFI and Linux: The Future is Here, and it's Awful") that the current EFI standard is so badly written and implemented that it amounts to security theater.

If that's the case, why are we pretending that this is a step forward, rather than a distasteful concession, given Microsoft's control of x86?

[1] http://youtu.be/V2aq5M3Q76U


(Log in to post comments)

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 13:39 UTC (Thu) by ndye (guest, #9947) [Link]

why are we pretending that this is a step forward, rather than a distasteful concession?

I think of it as air-dropping food to hostages who "buy" a Windows 8 computer and want to exploit "their" hardware, while others fight on the front lines, perhaps demonstrating the theatrical aspects of insecurable UEFI implementations.

But maybe that's just me.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 7:38 UTC (Fri) by Cato (subscriber, #7643) [Link]

Traditionally, many people have tried out Linux by installing it as dual-boot on a Windows PC, so this is actually quite important to the Linux community. A world where Windows 8 PCs can't easily have Linux installed will see much less growth in Linux usage, at least on PCs - and of course Windows 8 on ARM is completely locked down a la iPad.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 13:44 UTC (Thu) by dilinger (subscriber, #2867) [Link]

I don't think anyone is pretending that this is a step forward (well, other than Microsoft). From Matthew's blog post, "It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be."

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 14:00 UTC (Thu) by sblack (guest, #81076) [Link]

I do see that, but it seems that he's only bemoaning having to use Microsoft's key. Otherwise, it looks like Fedora is planning to take UEFI seriously:

"Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled."

Taking it seriously

Posted May 31, 2012 14:59 UTC (Thu) by corbet (editor, #1) [Link]

There is value in the concept of ensuring that your computers are running only the software you want to be there. Beyond that, I can imagine that Red Hat has plenty of customers who would be entirely pleased to know that their systems will not boot if the kernel or bootloader have been tampered with. Yes, it's a feature worth taking seriously. UEFI has lots of problems, but so do the BIOSes that preceded it.

The sticking point, is always, is who holds the keys. As long as the owner of a computer can control what runs on it, life is good. Retaining that control will be something we have to fight for, as always.

Taking it seriously

Posted May 31, 2012 22:30 UTC (Thu) by ballombe (subscriber, #9523) [Link]

> There is value in the concept of ensuring that your computers are running only the software you want to be there.

Unfortunately, this value is 99$, so the proposed solution does not provide any security.

Taking it seriously

Posted Jun 1, 2012 17:15 UTC (Fri) by AndreE (guest, #60148) [Link]

So would this scheme be better if the cost of signing was $100,000?

In any case, you aren't paying for a signing certificate, you are paying for Microsoft to analyse your and sign your binary. There is a difference.

Taking it seriously

Posted Jun 1, 2012 0:31 UTC (Fri) by gmaxwell (guest, #30048) [Link]

Er. if you have access to the hardware you can just disable secureboot. If you don't— you'd have to first exploit the kernel to replace the bootloader/kernel, and if you can do that you don't have too much need to replace the bootloader/kernel. (Just put your rootkit in systemd so that it reexploits the system at every bootup).

(Though the the other person saying the keys cost $99— not so, you can manually install your own keys for free. The $99 is what it costs to get a key that will work on other people's hardware... though perhaps it's misleading to call it $99, it'll have to be $99 plus some kind of certification since I'm pretty sure malware authors can spare $99. I have no idea how they'll tell linux devs apart from malware authors other than by only licensing billion dollar Linux distributors)

Taking it seriously

Posted Jun 1, 2012 16:42 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> reexploits the system at every bootup

That can only happen after it starts running arbitrary user code, and even then the exploit can't modify anything signed or it wouldn't validate on the next bootup. Even in the case where someone has spend the $99 to sign malware you can identify and revoke it and break the re-exploitation cycle. The benefit is an immutable set of tools early in boot to clean out malware.

Taking it seriously

Posted Jun 1, 2012 17:08 UTC (Fri) by AndreE (guest, #60148) [Link]

I don't believe this would work. UEFI in secure mode won't load a bootloader that isn't signed with a recognisable key. So you can't just replace the bootloader and be on your way.

As for physical access, well then yes in that case all bet's are off. If you have physical access rather than disable secure boot you should add your own key and run your self-signed malware silently.

Taking it seriously

Posted Jun 1, 2012 17:24 UTC (Fri) by gmaxwell (guest, #30048) [Link]

You don't replace the bootloader. You replace the first unsigned thing that runs— in the solution described for Fedora this would be systemd. Systemd would then execute the kernel exploit and intercept IO from the update process in order to make updates invisibly fail.

You only get the benefit if you sign and lock down 100% of the software which will run before updates are applied from the network. Perhaps thats viable on windows, though I'm doubtful. Regardless, what's suggested for Fedora would not have that property.

Taking it seriously

Posted Jun 1, 2012 17:37 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Packages are already signed so extending the signature checking system much more widely is likely to happen. At the very least a small base could be validated, including enough to clear out malware and break the cycle of re-exploitation.

Taking it seriously

Posted Jun 1, 2012 17:59 UTC (Fri) by gmaxwell (guest, #30048) [Link]

It's not at all the same kind of signing. The package signing is (IIRC) on the compressed data, and it requires the entire userspace stack to get to it (e.g. libc).

Taking it seriously

Posted Jun 1, 2012 20:45 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I understand that, what I was trying to communicate (poorly), is that if there was a system to include signatures with binaries that the kernel could check then the vast majority of userspace could be signed. We already deal with keys and signing for userspace software at the package level so it would only be an incremental extension on the systems which are already in place. Even though there would be security vulnerabilities in userspace that would allow malware to be injected through signed/verified software, there should be enough core, immutable tools to be able to clean it up. Without signature checking all the way from the firmware init you can't build an immutable infrastructure at all, with signatures you can (up until the point where you have an attack surface).

Taking it seriously

Posted Jun 1, 2012 21:09 UTC (Fri) by gmaxwell (guest, #30048) [Link]

Fair enough— but stand back and think about that.

What makes Fedora strong compared to Microsoft? Microsoft is the dominant player, Microsoft can employ many more designers— and out spend Fedora in every way, Microsoft can set a more consistent vision for the developers of the software they ship. Microsoft can hire almost any talent they like. These are all formidable strengths and they have many others.

What can't Microsoft do? Their business model is fundamentally incompatible with giving users an operating system which they— or their designees— can easily and legally change. Microsoft can't deliver a self-contained self-hosting system that with a few commands can patch and recompile anything it runs. It's incompatible for giving users access to the complete source code for everything they run, thus lowering the learning curve and turning out an endless stream of new developers.

Linux distributions could start engaging in top to bottom signing of userspace binaries— but in doing so it would be weakening the strengths of the open world and playing into pattern of top down control which they are fundamentally better at. Even if there are magic buttons and procedures you can add to regain these freedoms, and even if you ignore that one of the most important software freedom's is the freedom to share the results of your modifications and have other people able to use them easily... the additional friction of having to disable that 'security' diminishes our communities advantages.

There absolutely are applications for locked down machines where doing so provides a distinct advantage to the owner of the machine. But these applications are not typical for Fedora. I think it would be arguably in the GNU/Linux communities long term to leave those markets to special case distributions— or even to Microsoft.

I strongly support improved security— but there are a great many things which can be done to provide a more material improvement than codesigning without the compromises. The immutable boot only lets the horse be put back in the barn without reimaging the system— but by then it may be too late. At the point of initial compromise the users data may have been copied and erased, their bank accounts emptied, bitcoins stolen, whathave you.

If all you really care about is making sure that botnets don't persist then perhaps secureboot plus a sufficient amount of signed userspace is enough. But it's pretty weak from the perspective of actually securing the user.

We're hardly making use of SELinux, for example— Why are programs like Pidgin, Evince, and Firefox able to access my home directory except via a carefully audited privileged separated filechooser app? Why aren't they running in a sandbox? Why have we not built accelerated versions of tools like valgrind which are able to provide even stronger sandboxing than SELinux around the most vulnerable code? I could fill pages of things which would provide more security improvement for users than code signing without diminishing our fundamental advantage vs the closed software world. If it's security we're trying to get— why would we first do the one thing that makes us more like Microsoft?

Taking it seriously

Posted Jun 2, 2012 4:48 UTC (Sat) by raven667 (subscriber, #5198) [Link]

I think we are having a good discussion here. Yay!

> What makes Fedora strong compared to Microsoft? [...] Microsoft can [...] out spend Fedora in every way, Microsoft can set a more consistent vision for the developers of the software they ship.

MS can do extensive QA and UX testing but they don't have a monopoly on smart people or good designs and in my judgement MS seems pretty poor at having a vision and organizing their labor in any sensible way. Their recent attempt at coherence around "Metro" is a refreshing exception for a company who's major applications all use different custom UI toolkits that only superficially resemble each other.

> Their business model is fundamentally incompatible with giving users [...] access to the complete source code for everything they run

The industry behaves as if this were true so for practical purposes it is true but RedHat shows that there is plenty of business in selling the binaries while giving away the source, protected by Trademark more than Copyright, although the success of other Linux business indicates that there may only be room for one major player selling binaries based on the same source as other minor players.

> Linux distributions could start engaging in top to bottom signing of userspace binaries— but in doing so it would be weakening the strengths of the open world [...] the additional friction of having to disable that 'security' diminishes our communities advantages.

I don't believe this at all. As long as you can load your own keys or disable the secure boot from the physical machine then anyone who is a "developer" and wants to work with source can do so. I think working with source is a much bigger hurdle than changing a firmware setting or a jumper or loading a key.

> I think it would be arguably in the GNU/Linux communities long term to leave those markets to special case distributions— or even to Microsoft.

I disagree again. Having user unfriendly defaults is not in the long term interest of GNU/Linux. Making all users, including non-developers, go through what you yourself describe as "additional friction" and then not taking advantage of available technology is not a positive thing. To re-iterate, I don't think the additional friction of modifying secure boot is a problem for developers but I do think it is a (small, unnecessary) problem for non-developer users.

> I strongly support improved security

I do too.

> but there are a great many things which can be done to provide a more material improvement than codesigning without the compromises.

It doesn't have to be either/or, that's a false dichotomy

> The immutable boot only lets the horse be put back in the barn without reimaging the system— but by then it may be too late. At the point of initial compromise the users data may have been copied and erased, their bank accounts emptied, bitcoins stolen, whathave you.
If all you really care about is making sure that botnets don't persist then perhaps secureboot plus a sufficient amount of signed userspace is enough. But it's pretty weak from the perspective of actually securing the user.

Yep, that's all its trying to do, it doesn't cure cancer or cook a perfect steak either.

> We're hardly making use of SELinux, for example— Why are programs like Pidgin, Evince, and Firefox able to access my home directory except via a carefully audited privileged separated filechooser app? Why aren't they running in a sandbox? Why have we not built accelerated versions of tools like valgrind which are able to provide even stronger sandboxing than SELinux around the most vulnerable code?

This is a whole 'nother discussion. It would be great if we could do a ground-up re-design of how operating systems and applications work to help enforce this kind of sandboxing and seperation. I think that ultimately, in the coming decades, so much of application technology is going to be sucked into the web browser that this is the place to focus, as is being done in all the major browsers.

> If it's security we're trying to get— why would we first do the one thing that makes us more like Microsoft?

I am not primarily a MS technology user, apparently I'm obligated to say that up front, but it's not productive to act like MS has cooties or something. One sees the same thing whenever a discussion of Mono comes up. They may be stupid and evil on many levels but that doesn't mean that all their technology is bad or that changes they make to the marketplace can't be put to good use. All this crypto stuff can be used for both evil and good purposes, the fact that bad things can be done doesn't mean that we shouldn't do the good things.

Taking it seriously

Posted Jun 1, 2012 18:01 UTC (Fri) by AndreE (guest, #60148) [Link]

You're right...extending it to init at least is needed

Taking it seriously

Posted Jun 1, 2012 18:14 UTC (Fri) by gmaxwell (guest, #30048) [Link]

At a minimum, but realistically network manager too, since you need to be able to get updates before any unsigned code runs. $ ldd /usr/bin/nm-tool | wc -l ... returns 30 libraries.

I suppose that init could implement simple dhcp support and a cutdown emergency updater. But this is just a lot more stuff and a big change from how things work in Linuxland.

Taking it seriously

Posted Jun 1, 2012 20:26 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

You don't really need to validate the channel over which the update is downloaded (which would essentially require validating the entire Internet). You just need to validate the signature on the update itself before applying it, which can be done with a much smaller core of verified code.

The unverified code could _block_ the update, of course, but that could happen anyway: upstream ISP blocks the connection, someone pulls the physical ethernet plug, system experiences a DoS attack, etc. If this is a problem, the secure boot code could require a new, signed update after a given number of reset cycles. The update server would need to attest that the update is current, e.g. by signing the reset count at the time the update was downloaded, signed in turn by the boot code.

Taking it seriously

Posted Jun 1, 2012 20:49 UTC (Fri) by gmaxwell (guest, #30048) [Link]

I'm not saying you have to validate the channel, I'm saying that you can't execute any unsigned code in order to get access to the channel. At least with our current software infrastructure in Fedora we're using millions of lines of code before we can get a system online.

Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.

Or to put it more simply— What _goal_ (not mechanism) of an attacker will SecureBoot in Fedora thwart. It's advertised on windows as preventing unremovable rootkits, but I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace or moving a lot of networking code into init/systemd.

Taking it seriously

Posted Jun 1, 2012 21:37 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.

Not if the update process is sane. The unsigned code connects to the Internet, downloads the signed update, and stores it somewhere the boot code can access. You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and, if the signature is valid, applies it. The kernel never has write access to the secure boot parameters, so a kernel exploit can't undermine the update process beyond blocking the update.

To address that case, when the last valid update becomes too old the system can refuse to boot in secure mode, which should be fairly noticeable. A less drastic measure would be for the secure code to simply report the release date of the last update on startup, though that requires you to trust your display path.

Taking it seriously

Posted Jun 2, 2012 6:54 UTC (Sat) by dilinger (subscriber, #2867) [Link]

After my exploit takes over the system, I replace your unsigned code with my own. It pretends to download the secure update, but either a) doesn't, or b) just re-downloads an older (still exploitable, and very much signed/valid) update.

You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and.. whoops, there is no update (or we apply an older update if the user expects to see something happen). The system boots up, the exploit is re-run, and the user has no idea that they're still running an old version.

Taking it seriously

Posted Jun 4, 2012 4:43 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't understand why a secured, trusted process would have a dependency on an exploitable unsecured process. That doesn't seem like a sane design

Taking it seriously

Posted Jun 2, 2012 3:48 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace

I think you're expecting the cart to be in front of the horse. Of course you only have a trusted code path as far as you've implemented a trusted code path. There is no point in implementing the userspace or even kernel checking until the lower layers are done because you could always hide a persistant rootkit one layer down than what you are checking. Building on the secure boot framework, now that it exists, will allow the other checks to happen, but it is not that implementation.

Taking it seriously

Posted Jun 4, 2012 14:21 UTC (Mon) by hummassa (subscriber, #307) [Link]

> There is value in the concept of ensuring that your computers are running only the software you want to be there.

Unfortunately, this is not possible.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 13:45 UTC (Thu) by carenas (guest, #46541) [Link]

IMHO because the alternative would be to not have Linux booting at all if secure booting is enabled and which is likely to be the default with windows 8 provided systems.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 15:02 UTC (Thu) by hitmark (guest, #34609) [Link]

Question is if one has more of a leg to stand on with or without the implementation. In the end i guess we end up with the age old "open source vs free(dom) software" debate.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 13:46 UTC (Thu) by thumperward (guest, #34368) [Link]

Right now, anyone can burn a Linux distro install CD, boot a PC fresh from the store from it and install the distro with zero or minimal pre-configuration (the only potential barrier being the BIOS boot order). It would be a step backwards not to be able to do that any more, which is the reality as soon as UEFI secure boot is enabled on new PC hardware (absent the work detailed in the article). This is likely to happen within a timespan of months.

Yes, in this case Linux is having to run as fast as it can just to stay in the same place. But there simply isn't an alternative. OEMs are not going to sacrifice their "Certified for Windows 8" stickers based on political pressure from the Linux desktop distributions. And users who are told that the only way to install Linux is to fiddle about in their computer settings in order to disable a security feature will simply not install Linux.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 14:42 UTC (Thu) by pboddie (guest, #50784) [Link]

And once again we may ask where the regulatory authorities are.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 15:02 UTC (Thu) by thumperward (guest, #34368) [Link]

On the platform upon which Microsoft has a monopoly on operating systems, the standard mandates that users be able to install their own keys (and thus be able to use the secure channel) or else disable secure boot. Moreover, Microsoft is not dictating that OEMs preinstall only Microsoft's key, or indeed that they preinstall it at all. It's all very well shouting "monopoly!" given the undoubted advantage this gives Microsoft over other OS vendors, but the standard already offers sufficient concessions to said vendors that they are not being shut out of x86 entirely. It's difficult to see what a regulatory body could add to that.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 18:20 UTC (Thu) by pboddie (guest, #50784) [Link]

Microsoft never openly dictates what OEMs do, but the OEMs still manage to fall into line. Should no-one wonder why that is?

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 18:31 UTC (Thu) by thumperward (guest, #34368) [Link]

They are not "falling in line". They are "doing the bare minimum required to sell their product". And for the more Slashdot-prone in the audience, it is in fact the case that the sort of thing which saw Microsoft actually sanctioned for abusing their monopoly *was* "openly dictating what OEMs do", in the form of forbidding them to allow for dual boots at all. MS are being clever here and allowing simple economics to achieve the hoped-for result.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 20:57 UTC (Thu) by drag (subscriber, #31333) [Link]

Yes. What Microsoft did that got them into trouble was restricting access to their software for companies that were selling rival operating systems.

So if you had a store and you were selling BeOS systems and Microsoft decided that they didn't like it then you would not only have to pay more for your Microsoft software you would get it later then your competitors which put you at in a potentially significant disadvantage.

Personally I think that they should of just let Microsoft do whatever they wanted. The whole lawsuit was just one fairly evil proprietary software company fighting against another fairly evil proprietary software corporation.

The difference between Microsoft and it's failed competition was not due to Microsoft being evil or monopolistic practices. They were all immoral. Microsoft was simply better ran company which sold cheaper software.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 12:01 UTC (Fri) by pboddie (guest, #50784) [Link]

I guess you both don't remember the days when Microsoft insisted on being paid licensing fees for every x86 CPU shipped in a computer regardless of whether any software was being provided at all, apparently justified after the fact by the same argument that has people paying the music and movie industries every time they buy blank media because they are, of course, going to use it to copy music and movies.

Whether such practices are enforced overtly or through "incentives" is not a distinction that should automatically determine whether a regulator should take action or not.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 17:04 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

>Whether such practices are enforced overtly or through "incentives" is not a distinction that should automatically determine whether a regulator should take action or not.

It is, though, for the following reason:

"Incentive" implies some sort of trade-off (for example, Microsoft's bullying makes their software less useful and them less trustworthy, and they know they can only go so far before OEM's find it profitable to start selling no-OS or Linux systems).

It also requires the trade-off to be sustained for as long as Microsoft wants people to produce computers with their keys. So if Microsoft were to become a much smaller player in the market one day -- and looking at Windows 8, I expect this to happen soon -- they would be forced to stop pulling this crap.

To contrast, your example of us paying media companies for blank media, has none of the above. It was imposed by regulators (congress/parliament), working for a cabal of other regulators (RIAA/MPAA) with no trade-off, no choice, no accountability and no time limit. The fact is that the record companies would have failed years ago with such a poor business model, and the only reason they are alive today is because of regulatory capture.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 19:43 UTC (Fri) by pboddie (guest, #50784) [Link]

Firstly, you haven't really made the case for the distinction. Of course an incentive is a trade-off, but it's really just a way of pursuing the same policy without forcing anyone (the vendors or regulators) to take drastic action.

If vendors refused to follow any rules laid down by Microsoft, then Microsoft might deny them the ability to bundle Windows (technically or contractually), and that would potentially force them to look elsewhere for business or to complain about it to a higher power. However, since most vendors are heavily dependent on being able to provide Microsoft products because of the retail climate being distorted in the company's favour, most would be likely to go along with almost anything.

Offering incentives instead of making threats allows Microsoft to look like the good guy whilst making the transaction look like a positive thing, even though the effect of not taking up Microsoft's "generous" offer will result in relegation to a disadvantaged position for any vendor not wishing to play along.

And my example about blank media was concerned with per-processor licensing fees. The "justification" for this was that people would always be running Windows but might refuse to pay for it bundled, and that Microsoft should therefore get a guaranteed fee as compensation for all those "pirates" who couldn't possibly want to run anything else. The regulators put a stop to this, but then Microsoft went and integrated DOS and Windows shortly afterwards, so it was merely a tactical retreat to prevent more serious regulatory measures being imposed that might undermine that very strategy.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 13:59 UTC (Fri) by mcoleman (guest, #70990) [Link]

Re "It's difficult to see what a regulatory body could add to that.", let me help you out.

They could forbid this anti-competitive behavior.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 14:34 UTC (Fri) by thumperward (guest, #34368) [Link]

What "anticompetitive behaviour" are just suggesting be "forbidden" here? Do you suggest that a regulatory body could ban OEMs from shipping Microsoft's key, or demand that UEFI secure boot be disabled by default on all new computers, or that the Unified EFI Forum itself be disbanded and the standard torn up?

It is not difficult for any moderately intelligent person to see that at each stage, Microsoft has plenty of wiggle room in stating that choices are provided and that competitors are not locked out. Microsoft's lawyers would have no difficulty whatsoever in impressing that upon any regulatory body.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 16:46 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Those are absurd suggestions, straw men to be easily dispatched. Other articles from Matt Garret discussed some alternative approaches to UEFI key management that could make this feature more vendor and user friendly that you may be interested in reading.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 16:02 UTC (Thu) by drag (subscriber, #31333) [Link]

> And once again we may ask where the regulatory authorities are.

The regulatory authorities are happily making the situation vastly worse with implementing things like DMCA, ACTA, software patents, wiretapping efforts, copyright enforcement, etc etc.

They are not on your side. They will never be on your side.

Their purpose in life is just to do whatever will benefit themselves above all else and will happily side with whoever is able to provide them the most benefit. This usually is with whatever group will offer the most interesting chances at monetary and power gains.

Implementing UEFI Secure Boot in Fedora

Posted Jun 1, 2012 1:00 UTC (Fri) by nix (subscriber, #2304) [Link]

Yes, thank you, we all know your tiresome politics by now. Can't you take it to a blog post or something?

Implementing UEFI Secure Boot in Fedora

Posted Jun 2, 2012 11:59 UTC (Sat) by efraim (guest, #65977) [Link]

Actually I found the grand-parent post informative. Policy discussions (such as regulations) ARE inherently about politics.
So I would appreciate if you stop shutting up whoever voices a position you do not agree with.
Though I rarely post here I read the comments here a lot and I usually find your posts quite enlightening - this one is not.

Implementing UEFI Secure Boot in Fedora

Posted Jun 4, 2012 12:55 UTC (Mon) by nix (subscriber, #2304) [Link]

It's not that I disagree with his position, it's that he has only one position, and never backs it up beyond (as far as I can tell) an axiom that everything governments do is ipso facto bad while if a corporation does the exact same things it is ipso facto not bad, or at least not worth caring about. These axioms are sufficiently far removed from the realities of present-day political systems as not to be worth basing anything but pie-in-the-sky discussions on.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 18:22 UTC (Thu) by nickbp (guest, #63605) [Link]

They're in the continual process of being de-funded.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 19:06 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

And once again we may ask where the regulatory authorities are.

In the pockets of the industries they're supposed to be regulating- exactly where the rich and powerful want them to be.

Implementing UEFI Secure Boot in Fedora

Posted May 31, 2012 20:47 UTC (Thu) by drag (subscriber, #31333) [Link]

It makes it easier to understand what is going on when you realize that the people that run the regulatory agencies and the people that run the companies that are suppose to be regulated are pretty much the same group of people.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds