LWN: Comments on "Fedora, secure boot, and an insecure future" https://lwn.net/Articles/500231/ This is a special feed containing comments posted to the individual LWN article titled "Fedora, secure boot, and an insecure future". en-us Sun, 14 Sep 2025 09:52:33 +0000 Sun, 14 Sep 2025 09:52:33 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Fedora, secure boot, and an insecure future https://lwn.net/Articles/502843/ https://lwn.net/Articles/502843/ mjg59 <div class="FormattedComment"> Nothing. Then you just have to get every manufacturer to include them. If you want to run a signing service then you'd also need to handle identity verification, key security and revocation. That's likely to cost rather a lot<br> </div> Thu, 21 Jun 2012 13:10:47 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502816/ https://lwn.net/Articles/502816/ jimbo <p>Can't we get our own set of keys? This would ensure that we don't have to <em>rely</em> on Microsoft being good guys in the future.</p> <p>Just how much do UEFI signing keys cost? </p> --<br/> jimbo Thu, 21 Jun 2012 06:09:49 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502765/ https://lwn.net/Articles/502765/ Cyberax <div class="FormattedComment"> <font class="QuotedText">&gt;The OS cannot verify what the firmware tells it, so this information is not useful for DRM.</font><br> That's temporary. The next step is integration with TPM to measure the UEFI integrity.<br> </div> Wed, 20 Jun 2012 19:53:23 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502754/ https://lwn.net/Articles/502754/ BenHutchings <blockquote>They know or will know how to disable secure boot and it would not deter them from using Linux if they could do.</blockquote> <p>What if they're installing it for someone else? Having to find and disable that option is an additional barrier; you'll probably spend the time to do it for your own PC but are more likely to give up on someone else's. Also, what if the other person is a bit naive about downloading programs and would benefit from that protection against malware?</p> <blockquote>Paying $99 is just supporting and putting Microsoft in a better position than they are now...</blockquote> <p>The money goes to Verisign, supposedly subsidised by MS.</p> <blockquote>Well we just edit the kernel... but hang on that windows update last week meant I can no longer disable secure boot....</blockquote> <p>But you can run it in a VM in which you have a modified UEFI that always says 'Secure Boot is enabled'. The OS cannot verify what the firmware tells it, so this information is not useful for DRM.</p> Wed, 20 Jun 2012 18:45:46 +0000 PC suppliers, and the commercial impact of secure boot on them https://lwn.net/Articles/502750/ https://lwn.net/Articles/502750/ BenHutchings <div class="FormattedComment"> You can't install an OS you don't trust and somehow configure it into an OS you do trust. How can you know it really follows your configuration, and doesn't have a secret backdoor?<br> <p> </div> Wed, 20 Jun 2012 18:35:23 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502473/ https://lwn.net/Articles/502473/ Cyberax <div class="FormattedComment"> I'm using my homegrown secure boot + remote attestation solution for physical security of servers containing medical data. Right now it's cobbled from BIOS with TPM support.<br> <p> Ultimately, secure boot is a good thing. However, the way it's being implemented is far from perfect. By about ten light-years.<br> </div> Mon, 18 Jun 2012 19:24:30 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502469/ https://lwn.net/Articles/502469/ mathstuf <div class="FormattedComment"> What's wrong with the kernel (and other software) being compatible? Should a company or school not be allowed to force that students use their vetted Linux distro/version combo rather than some custom distro? I would like to ensure my servers are using the right versions of things. I'd use my own key, but if we said "Linux shouldn't even support SecureBoot" then this isn't possible. Having a distro get a key from Microsoft or using its own key are separate things.<br> </div> Mon, 18 Jun 2012 19:06:46 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502418/ https://lwn.net/Articles/502418/ josephkliener <div class="FormattedComment"> Actually it is more than $99.<br> <p> It is also the wasted time and red hat or community money and resources making a secure boot compatible kernel... this is $100,000's of work and man hours.<br> </div> Mon, 18 Jun 2012 15:32:41 +0000 PC suppliers, and the commercial impact of secure boot on them https://lwn.net/Articles/502412/ https://lwn.net/Articles/502412/ josephkliener <div class="FormattedComment"> I trust myself. I would not even trust red hat with a forced global key. At least with the repository PGP keys it is my choice to install them. They don't come pre-installed.<br> </div> Mon, 18 Jun 2012 15:22:36 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/502410/ https://lwn.net/Articles/502410/ josephkliener <div class="FormattedComment"> Time and time again, it was even said by Linus himself. Linux should be focusing on pre-installed systems. <br> <p> The user who knows how to download Linux, put it onto a USB stick or USB, restart their computer (potentially have to press the boot menu key for their computer) and run or install Linux. They know or will know how to disable secure boot and it would not deter them from using Linux if they could do. The user that Fedora and Gnome 3 are tailoring their user friendliness to does not exist. 99% of people if it does not come pre-installed they will not change. How do you think people find about Linux? Is there any T.V. Advertising? This kind of attitude is ridiculous. Paying $99 is just supporting and putting Microsoft in a better position than they are now... which currently is failing in every market. Some of these guys are so old and stuck in the 90's thinking that Microsoft on desktop is still the relevant target. The Tablet and Mobile market and some lesser extent Mac is where it is all concentration is at the moment, and you guys are ignoring ARM (which may be a waste of time or it may overtake x86). Secure boot and Windows 8 are aimed for high-end systems currently (e.g. ultrabooks), and these are going to be direct competition with MacBookPros and iPads.... if you were an un-informed consumer, who could not disable secure boot which one would you buy?<br> <p> Also I have no idea why you cannot see that Secure Boot is supportive of a DRM system. Sure if you are talking proper access control, with a crypto module and tamper resistance, and remote attestation. Yes it does not support that. But what sort of DRM do we have at the moment? Well it is software based, and can be circumvented by say, using software to dump the memory or effectively installing your own root kit. Well what happens if Windows supports software DRM at the kernel level and prevents memory dumping of a certain application? You have to edit the kernel to circumvent the DRM for your system. What happens if at the kernel level it requires the user space code to be signed by Microsoft and downloaded from the Microsoft store. Well we just edit the kernel... but hang on that windows update last week meant I can no longer disable secure boot.... I cannot boot if I try to circumvent the DRM... Okay so I will have to flash the hardware manually... wait a minute the manufacturer has hard coded their certificate into the chip... crap DMCA territory. <br> <p> This is exactly how the iPhone works and jailbreaking iPhones has a specific exception granted to it that might or might not be granted if secure boot was one day disallowed from being disabled.<br> Sure their are ways around certain aspects, the system does not have any real unique identifier that cannot be faked, but as it stands currently windows advantage or whatever uses a bunch of ridiculous random hashes of bios, cpu, driver information. The uniqueness required for DRM is included in the software key, which will disable windows update, etc. if it detects it is circumvented already.<br> Companies want DRM at any level, they would even accept obfuscation as a form of DRM if they thought it would stop even 1 person from pirating their stuff. All it takes it one person to go.... hey wait a minute if we stop people from disabling secure boot we could be in a better place than we are now.... this would trump whatever anti-trust people would through our way.<br> <p> Sure you could install pirated software on a pirated copy of windows on a computer without secure boot. But in 5 years time you will be stuck with old hardware, as everything you want to buy will come with secure boot.<br> <p> I mean another example could be on a system with windows 8 starter, black list the signatures for windows 8 home, and premium, ultimate etc. then if they purchase the upgrade you use windows update and the manufacturer's key to un-blacklist the version of windows they purchased. How can you say this is not DRM...<br> <p> Coreboot support and linux on pre-installs is the way forward. That $99 could be spent elsewhere. Save the pennies and the dollars will look after themselves<br> </div> Mon, 18 Jun 2012 15:09:20 +0000 PC suppliers, and the commercial impact of secure boot on them https://lwn.net/Articles/502267/ https://lwn.net/Articles/502267/ jdobbs1010 <div class="FormattedComment"> The company where I work has recently migrated from Windows XP to Windows 7 as the standard corporate desktop for its entire workforce. Its taken them a long time and a lot of money to do this. I doubt they will be rushing out to buy Windows 8/secure boot hardware for a few years to come. I've also read in the IT press how Windows 8 is likely to flop like Vista. I suspect there's going to be a lot of Windows 7 desktops around for quite some time to come in the corporate world. Which means corporate PC suppliers (HP etc) must sell PCs that can have this feature disabled if they want the corporate business. I am imagining a little switch at the back, turning secure boot on and off, like the little piece of plastic on 3 1/2 inch floppies to toggle the read-only. Worse for the casual user would be a jumper on the motherboard (if motherboards still have jumpers nowadays)<br> <p> Another question raised in the comments was 'who would step up and manage a key independently of Microsoft'. What about a big PC vendor? They surely have in interest in it, and might get a competitive advantage - as long as its OK to have 2 keys on the same machine, then why wouldn't they? (apart from risking Microsofts ire). They could even charge something for a 'free software key'. I'd be happier paying that, than a Microsoft tax. <br> <p> That said, the whole scheme is a recipe for abuse by commercial interests. Some entity has to manage the keys, and hence has power over the hardware owner. Power corrupts etc. Who would you trust - Microsoft? HP? Verisign? Your government? Redhat board of directors? Those Debian fanatics? FSF? Pick your poison!<br> </div> Fri, 15 Jun 2012 22:43:08 +0000 Other long term problems https://lwn.net/Articles/502004/ https://lwn.net/Articles/502004/ etienne <div class="FormattedComment"> Why would you write the current time in the FLASH? It would be out of date pretty quickly... The copy of the ACPI variables in RAM are updated all the time, as needed, but it is not my point.<br> What I noticed is that the FLASH CRC32 was switching in between two values, then I tried to limit the FLASH checkuming part to what is visible (real-mode address 0xE000:0000 to 0xFFFF:0000) but it did not work neither.<br> </div> Thu, 14 Jun 2012 15:45:20 +0000 Other long term problems https://lwn.net/Articles/501988/ https://lwn.net/Articles/501988/ JanC_ <div class="FormattedComment"> The *current time* is updated quite often indeed... ;)<br> </div> Thu, 14 Jun 2012 14:09:33 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501983/ https://lwn.net/Articles/501983/ JanC_ <div class="FormattedComment"> Those numbers were for sales last year BTW.<br> </div> Thu, 14 Jun 2012 13:52:52 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501970/ https://lwn.net/Articles/501970/ JanC_ <div class="FormattedComment"> Canonical mentioned recently that they know about something between 8-10 million computers being sold with Ubuntu pre-installed by OEMs. That's already more than the number of PCs sold with Mac OS X pre-installed, and I'm sure it's more than enough for MBAs not to laugh at it...<br> </div> Thu, 14 Jun 2012 13:51:15 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501943/ https://lwn.net/Articles/501943/ mjg59 <div class="FormattedComment"> Right now you can't buy any motherboards that implement secure boot at all. No signed operating systems have been released yet - what would the boards boot?<br> </div> Thu, 14 Jun 2012 12:05:33 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501942/ https://lwn.net/Articles/501942/ mjg59 <div class="FormattedComment"> That's why you're able to revoke binaries at the firmware level.<br> </div> Thu, 14 Jun 2012 12:03:58 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501925/ https://lwn.net/Articles/501925/ tonyblackwell <div class="FormattedComment"> lLts of erudite discussion here, but I can't find anything relating to the immediate practical problem. Are there any currently available motherboards which implement UEFI but also provide a BIOS way to disable secure boot for linux? <br> <p> From my attempted discussions with Gigabyte and ASUS the answer from both of these appears to be 'no', although it was conducted in English text with folk who may have missed the point.<br> <p> Amoungst our community, does anyone have higher-level contacts than just their generic web interface to get some answers? - or at least discuss the issue?<br> <p> </div> Thu, 14 Jun 2012 09:51:22 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501879/ https://lwn.net/Articles/501879/ kevinm <div class="FormattedComment"> It doesn't matter if you release an update for the signed bootloader that refuses to boot the known-buggy kernel, because the original signed bootloader that *doesn't* have that update is still out in the wild. Malware that wants to take over Windows machines will simply use the un-updated signed bootloader together with the signed buggy kernel.<br> </div> Thu, 14 Jun 2012 05:07:57 +0000 Other long term problems https://lwn.net/Articles/501874/ https://lwn.net/Articles/501874/ slashdot <div class="FormattedComment"> I predict that it will boot fine using the Awesome Genuine Trusted Signed Bootloader and Kernel, and then also happily run the malware from /etc/init, $HOME/.config/autostart, or similar.<br> <p> </div> Thu, 14 Jun 2012 03:03:44 +0000 Other long term problems https://lwn.net/Articles/501554/ https://lwn.net/Articles/501554/ mjg59 <div class="FormattedComment"> The crypto code itself is just openssl, and the interface on top is part of Tiano. So, thankfully, there's a single reference codebase for all of this.<br> </div> Tue, 12 Jun 2012 07:13:01 +0000 Other long term problems https://lwn.net/Articles/501551/ https://lwn.net/Articles/501551/ nix <blockquote> So in order to add keys to the white or blacklists, you need to have the private half of a key already. </blockquote> Aha, that makes sense. (And, again, had I done fifteen minutes of research rather than fifteen minutes' bloviating, I could probably have figured this out myself. So thanks for the information! :) ) <p> I have horrible visions of vendors' getting the setup mode wrong such that the Pk is changed instead, breaking future updates -- but incompetent though most BIOS vendors are, I suppose the Pk is probably burned into the hardware and unchangeable even by an idiot BIOS. <p> I must say the thought of BIOS vendors writing anything at all to do with crypto fills me with trepidation. I'm somewhat surprised that PCs can even boot reliably, with the boot process under the control of people as bad at writing code as BIOS vendors... adding extra complexity to this, particularly extra complexity designed to fail in the direction of not booting, seems seriously unwise to me. Tue, 12 Jun 2012 07:10:36 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501533/ https://lwn.net/Articles/501533/ bronson <div class="FormattedComment"> Complex, proprietary wireless stacks covered by tenuous patents.<br> </div> Tue, 12 Jun 2012 01:37:19 +0000 Other long term problems https://lwn.net/Articles/501520/ https://lwn.net/Articles/501520/ mjg59 <div class="FormattedComment"> There's three levels of key in this. The first is the platform key, or Pk. Below that are the Key Exchange Keys (KEK). Finally there's the actual signature keys, db (for whitelisted keys and hashes) and dbx (for blacklisted ones). KEK updates have to be signed with Pk, and Pk will generally be under the control of the hardware vendor. db and dbx updates can be signed with either Pk or any key present in KEK. So in order to add keys to the white or blacklists, you need to have the private half of a key already.<br> <p> Most users aren't going to have any of these private keys, so Microsoft mandate that it be possible to enter a "custom mode". The semantics of this aren't well defined, so it's valid for an implementation to manage it either by offering a firmware UI interface to enrol keys directly or to simply let the user delete all the existing keys which results in the system transitioning back to setup mode.<br> <p> If you have unauthenticated management interfaces on your network then you obviously deserve to lose.<br> </div> Mon, 11 Jun 2012 23:12:11 +0000 Other long term problems https://lwn.net/Articles/501507/ https://lwn.net/Articles/501507/ nix <div class="FormattedComment"> That's true. I didn't think of it until after posting, and I don't really want to wade into the EFI swamp right now anyway.<br> </div> Mon, 11 Jun 2012 22:03:18 +0000 Other long term problems https://lwn.net/Articles/501488/ https://lwn.net/Articles/501488/ raven667 <div class="FormattedComment"> <font class="QuotedText">&gt; It is possible that ...</font><br> <p> <font class="QuotedText">&gt; Now perhaps key updates and revocation ...</font><br> <p> <font class="QuotedText">&gt; So I guess I still can't see the point of all this.</font><br> <p> <p> This is an actual written standard with actual implementations, your assumptions are questions and those questions have answers. Instead of spilling a lot of ink with possibles and maybes it would be worthwhile to see how this stuff actually works.<br> </div> Mon, 11 Jun 2012 19:13:59 +0000 Other long term problems https://lwn.net/Articles/501396/ https://lwn.net/Articles/501396/ nelljerram <i> <blockquote> A few days ago, pjones wasn't even an LWN subscriber. </blockquote> pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918. </i> <p> True, but I thought I saw, a few (or several, now) days ago, "pjones (guest)". <p> But I could be wrong about that, and in any case it's a somewhat distasteful point to make, so please consider that withdrawn. <p> Regarding everything else you wrote: I agree, and thanks for expounding it so clearly. Mon, 11 Jun 2012 12:21:37 +0000 Custom key management https://lwn.net/Articles/501397/ https://lwn.net/Articles/501397/ nix <blockquote> removing all existing keys and uploading a local key </blockquote> That sounds like you think that uploading a local key should require removal of the existing ones. Thanks, but no thanks: being able to boot from distro-provided rescue CDs is sometimes very useful! Mon, 11 Jun 2012 12:14:13 +0000 Other long term problems https://lwn.net/Articles/501392/ https://lwn.net/Articles/501392/ nix <blockquote> A few days ago, pjones wasn't even an LWN subscriber. </blockquote> pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918. <p> By extension, unless holes in the ID are being filled in, pjones has been reading LWN for a while. <p> I'm concerned about this problem too. As I see it there are two possibilities. Either updating keys and adding revocations is prohibited except in a special mode, in which case malware authors will copy whatever that mode is (if necessary by having kernel-mode code loiter and spy on an update in progress to observe variable parameters, before elevating themselves from kernel-mode to BIOS compromise), or updating keys is prohibited but adding revocations is not, in which case malware authors have an instant free DoS attack vector. <p> It is possible that, given a completely compromise-free kernel, malware could never run in kernel mode to spy on a key update -- but firstly a compromise-free kernel is a pipe-dream and secondly malware that couldn't even get to kernel mode could never compromise the BIOS in the first place. <p> So as far as I can see, as long as key updates or revocations are possible under software control at all this whole thing adds no security, adds a lot of inconvenience, and allows MS to prohibit other OSes from running on their ARM devices. (Which is the real point of all this.) <p> Now perhaps key updates and revocations cannot be scripted, and can only be triggered from the BIOS (which means Windows updates cannot provide revocations for insecure keys but can only ask the user to do it). Desktop PCs might be safe, but server-class PCs are not, because they generally allow remote access to their BIOSes using technologies like IPMI. So on such a network malware on *another* machine can watch for a server to start rebooting, add its own key pre-emptively, then later infect it and replace its firmware. In general non-scriptable updates hugely annoy IT staff in large organizations anyway because they mean some poor sap has to walk around physically from desk to desk. So I bet the thing ends up scriptable across all machines, which eliminates its security advantages. <p> Non-scriptable updates would mean that no keys ever got revoked on most desktop devices. So either this thing adds security only until the first key revocation (non-scriptable case) or it adds security only until the bad guys learn how to use a debugger, i.e. not at all (scriptable case). <p> So I guess I still can't see the point of all this. Mon, 11 Jun 2012 11:51:36 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501393/ https://lwn.net/Articles/501393/ cortana <div class="FormattedComment"> I've come to begrudgingly accept that proprietary graphics drivers are a fact of life, but I really don't understand the recent (or so it seems to be) fetish with proprietary ethernet drivers! A decade ago any cheap PC had an onboard VIA or Realtek ethernet interface that worked fine with open drivers... what has changed?<br> </div> Mon, 11 Jun 2012 11:50:58 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501390/ https://lwn.net/Articles/501390/ nix <div class="FormattedComment"> I'd have assumed that... but the company I bought Linux hardware from last is now selling machines advertised as 'Linux-friendly', every one of which requires a binary-only module for its network card and another binary-only module for its graphics. So allowing user recompilation of kernels doesn't seem to be a long way up vendors' priority lists :(<br> </div> Mon, 11 Jun 2012 11:37:09 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501190/ https://lwn.net/Articles/501190/ raven667 <div class="FormattedComment"> Yep, Fedora is not playing that game, they aren't going to to ship for Win8 logo ARM machines for this very reason.<br> </div> Sat, 09 Jun 2012 01:27:33 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501181/ https://lwn.net/Articles/501181/ wookey <div class="FormattedComment"> Except on ARM where you don't get the option of disabling it. <br> </div> Sat, 09 Jun 2012 00:28:30 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501069/ https://lwn.net/Articles/501069/ raven667 <div class="FormattedComment"> Hardware with the Win8 logo will be shipping with secure boot enabled by default, the MS keys loaded by default and must have the option to disable secure boot, they may also have the option to load their own keys. Fedora will be having their bootloader signed by MS because it's user-unfriendly to require a trip to the firmware to modify secure boot settings before booting an install CD. If you want to install custom software or older software (Win7 or whatever) you will have to fiddle with the firmware in any case.<br> </div> Fri, 08 Jun 2012 16:54:16 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501060/ https://lwn.net/Articles/501060/ raven667 <div class="FormattedComment"> <font class="QuotedText">&gt; Fortunately there are other comments on this article that claim that disabling is practically important for Microsoft, so there's hope...</font><br> <p> The obvious being that Win7 doesn't support secure boot and will need to run on Win8 hardware for the foreseeable future, both for home users and businesses. Maybe in 10+ years we'll be having this discussion again, but probably not before then unless secure boot somehow comes to Win7 via a service pack or something (and if MS are content to leave behind users who can't/won't upgrade software).<br> </div> Fri, 08 Jun 2012 16:33:04 +0000 Other long term problems https://lwn.net/Articles/501059/ https://lwn.net/Articles/501059/ raven667 <div class="FormattedComment"> <font class="QuotedText">&gt; Secondly there's the ethical point, that RH have chosen overall to give aid to a Microsoft-inspired and Microsoft-favouring system, and to make themselves hostage to that, instead of unequivocally fighting against that.</font><br> <p> You make it sound like treason, which is a ridiculous concept when applied to this case. Working with standards that MS also works with and has influence over is not an "ethical" challenge. Fedora and mjg59 have already stated their constraints, they are willing to work on secure boot on systems where key management is available to the end user (even if it isn't as user-friendly as they would like) and are not working on secure boot for systems which are boot locked, without key management (Win8 ARM).<br> <p> <font class="QuotedText">&gt; All in all, I'm afraid it's difficult for me to believe that there isn't an ulterior motive.</font><br> <p> This isn't a matter of faith, it's a matter of reading the very open dialog that exists. The fact that you see ulterior motives probably reveals more about your own thought process than illuminates the discussion.<br> </div> Fri, 08 Jun 2012 16:30:31 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/501022/ https://lwn.net/Articles/501022/ dgm <div class="FormattedComment"> <font class="QuotedText">&gt;&gt; As long as you have local key management and the option to disable your rights have not been infringed in _any_way_.</font><br> <p> <font class="QuotedText">&gt; This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.</font><br> <p> Gentlemen, you need to realize that the problem is not Fedora or what they do. The problem lies in those distributing Fedora, that is, the OEMs. If System77 or Dell ships a laptop with Fedora preinstalled, then they are the ones that _have_ to instruct the user on how to change the keys, should they want to.<br> <p> Fedora is just trying to be nice to people that didn't chose a preinstalled system, and instead just want to test the distro in hardware blessed for Windows 8. That you can do this is GOOD.<br> </div> Fri, 08 Jun 2012 13:13:47 +0000 Other long term problems https://lwn.net/Articles/501002/ https://lwn.net/Articles/501002/ brouhaha <blockquote> I would think they would go straight to TPMs. </blockquote> I'm sure Microsoft would like to that; they were behind the whole Palladium/Trusted Computing Initiative stuff, but they've already gotten a huge amount of pushback over that in their past proposals. For now they're trying to placate OEMs and customers by pushing something that doesn't increase the direct cost of the hardware. It has lots of indirect costs, but it's much easier to sweep those under the rug. <p> In the long run, I expect that Microsoft will try to get processor vendors to put keys and hardware, microcode, or a first stage boot in the processor itself (i.e., built-in TPM), so that it isn't even possible to run an unsigned BIOS/UEFI/coreboot/whatever. By building this misfeature into the processor, they can make the incremental hardware cost essentially zero. This will split the processor market into Windows and non-Windows processors, and there will naturally be a price difference based on the production volumes of the variants. This means that non-Windows desktop processors will cost more than Windows desktop processors, but unless Microsoft makes significant inroads on mobile devices, the reverse might be true there. It is thus ironic that Microsoft is focusing the majority of their so-called Secure Boot effort on the mobile market. Fri, 08 Jun 2012 10:44:36 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/500996/ https://lwn.net/Articles/500996/ drago01 <div class="FormattedComment"> <font class="QuotedText">&gt; This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.</font><br> <p> You still have this right (with or without secure boot). Fedora has no obligation by *any* license that can be called free to help your fork. Either by making there software less usable or anything else. All they have to do is to provide you the source and tools needed to create the fork. <br> <p> And they *do* that. You have the source. You have the tools. If you want to sign it ... fine pay the 99$ and go ahead. If you don't or even can't (because you cannot afford the 99$) that's fine as well this does not make the software any less free.<br> <p> By your logic Fedora is not free already because they have a competitive advantage over forks by having infrastructure (builders, mirrors, bug tracker...). All those cost way more then the stupid 99$. Oh and the trademark and marketing budget.<br> <p> This is not that hard to understand really.<br> <p> </div> Fri, 08 Jun 2012 10:27:06 +0000 Fedora, secure boot, and an insecure future https://lwn.net/Articles/500992/ https://lwn.net/Articles/500992/ ballombe <div class="FormattedComment"> <font class="QuotedText">&gt; Only if you want to be signed by the existing Verisign/MS authority, you can always be your own authority and have the end-user load keys in by hand.</font><br> <p> So far no evidence that 'loading key by hand' will be actually possible has been provided, and indeed this is one of the premise of the Fedora decision. You cannot have it both way.<br> </div> Fri, 08 Jun 2012 09:56:55 +0000