Forgot your password?
typodupeerror
SuSE

Secure Boot Coming To SuSE Linux Servers 135

Posted by Unknown Lamer
from the hold-the-key dept.
darthcamaro writes "UEFI Secure Boot is a problem that only desktop users need to worry about right? Well kinda/sorta/maybe not. SeSE today is releasing SUSE Linux Enterprise 11 SP3 which will include for the first time — support for UEFI Secure Boot. Apparently SUSE sees market demand for Secure Boot on servers too. Quoting Matthias Eckermann, Senior Product Manager at SUSE: 'Our market analysis shows that UEFI Secure Boot is a UEFI extension that does not only cover desktops, but might very well also be deployed and even required on server systems going forward.'"
This discussion has been archived. No new comments can be posted.

Secure Boot Coming To SuSE Linux Servers

Comments Filter:
  • by Anonymous Coward

    The new hotness is memory-resident. Everything old is new again.

    • 1,4Gb downloaded already, and only 11 Comments? What's wrong with this place? ;-)

      • Re: (Score:2, Insightful)

        by mystikkman (1487801)

        Most folks with half a brain cell have left because of the constant slanted summaries, biased moderation by people with an axe to grind and the constant FUD and lies being spread on here.

        http://mobile.slashdot.org/story/13/03/17/1914209/microsoft-to-abandon-windows-phone [slashdot.org]

        Don't think that the constant karma whoring and circlejerking by the likes of symbolset, bmo, etc. and the moderation does not have any ill effects. There's no place for rational discourse here, whoever posts the most anti-MS screed gets vo

        • by wbr1 (2538558) on Monday July 08, 2013 @11:26PM (#44221925)

          There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

          I am going to test your theory.

          MS Sucks balls, They have since 1978. In fact Gates dropped out because everyone's balls at Harvard were chafed from staying damp with Gates saliva.

          Balmer is CEO now, because he even has a ball in his name.

          If you look deep in the resources in shell32.dll, there is a string that reads, "insert balls into CD-ROM for a 'Gates job'."

        • by PopeRatzo (965947)

          There's no place for rational discourse here

          Please tell us when the Golden Age of Rational Discourse on Slashdot ended, sifu.

          I'd like to have some time-frame for my nostalgia.

          • by evilviper (135110)

            Please tell us when the Golden Age of Rational Discourse on Slashdot ended

            I'd say it was roughly around the time that your account was created, Ratzo...

            • by PopeRatzo (965947)

              Please tell us when the Golden Age of Rational Discourse on Slashdot ended

              I'd say it was roughly around the time that your account was created, Ratzo...

              I know, ain't I a stinker?

              I should be a little more careful with my powers.

            • Unfortunately, I held out on actually registering, and have a rubbish UID as a result. I still see logical, rational and funny discourse, and I've got quite a loose leash when I post silly things to cause trouble - things could be a lot worse for me here, with the things I post sometimes!

              I got the username I would have chosen though, I was webmistressrachel at Excite dot com while it was still going!

        • by evilviper (135110)

          There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

          On the plus side, the absolute FLOOD of inflammatory stories about global warming, evolution/intelligent design, has trailed off. Those were almost daily occurrences on the front page when CmdrTaco left, and the anti-XYZ bile in the comments was something to behold. You'd get a dogpile of angry replies and instantly modded down to -2 if you even offered small factual corrections to anti-X

  • by Junta (36770) on Monday July 08, 2013 @08:23PM (#44220969)

    SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for:
    -custom executables
    -configuration data and so on

    Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.

    It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.

    Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)

    • by bws111 (1216812) on Monday July 08, 2013 @08:45PM (#44221083)

      Secure boot only ensures that you know that what you are booting is signed by someone you trust. It does not provide 'attestation'. If you want attestation, use TPM, possibly combined with secure boot. TPM is not subject to being tricked by hypervisors.

      • Re: (Score:3, Insightful)

        by Junta (36770)

        My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executabl

        • by KiloByte (825081) on Monday July 08, 2013 @10:19PM (#44221587)

          It complicates use of non-microsoft OSes

          And that's the whole reason SecureBoot is getting pushed onto manufacturers.

        • If some well meaning but less than perfectly well informed member of a management team decides that there should be a policy requiring secure boot, then it might be nice for the product that it's able to comply. Certainly it would be better to properly educate management, but dealing with software might be easier.
        • SecureBoot doesn't ensure that your are booting is signed by someone you trust.

          Maybe what's needed is an additional piece like a programmable smart card that could carry a list of trusted sources. Then you could customize each system for exactly what is to be trusted on it in a hard to hack form. (Assuming the card reader is read only on that system.)

        • My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust.

          Yes it does. Especially on Windows, the OS is booted from signed cabinet files, i.e. the Microsoft bootloader will refuse to boot Windows unless the cabinet file (which include executables, libraries, core config files) is signed correctly.

          It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc,

          And if the bootloader and OS in turn takes on their part of that responsibility, you *do* have a trusted chain. Of course, it requires that the OS is booted from signed files that include executables as well as config. If the OS is set to require signatures (or hash match

      • Re: (Score:3, Insightful)

        by Nerdfest (867930)

        what you are booting is signed by someone you trust

        Or Microsoft.

    • by Chirs (87576) on Monday July 08, 2013 @11:22PM (#44221909)

      As I understand it, the signed redhat bootloader will only boot redhat kernels (which in turn will extend the chain of trust upwards). The generic linux bootloader will boot anything, but will require proof from a person that they acknowledge that it is booting that thing (in order to prevent a "blue pill" type attack).

      In this instance, the person with physical control over the system could load an arbitrary kernel, but it is difficult for an attacker to install a hidden rootkit.

    • by vojtech (565680)

      You might want to examine the MOK concept that SUSE has implemented. It allows for custom executables that are checked against a local key.

      Regarding configuration, that is outside of the scope of Secure Boot. Its purpose isn't a full system attestation, it's limited to preventing executing untrusted code in kernel space. That alone is of value, as it makes installing persistent and invisible rootkits much much harder. Not impossible, of course - as long as software can have bugs, no security technology can

  • good as MS ideas like metro on servers is dumb even more so the is the app store.

    Need an exit route if they go app store only.

    • by Nerdfest (867930)

      SecureBoot is designed to make that exit more difficult. You can get past it if you know what you're doing, but giving someone a Linux distro to install themselves via a USB boot no longer as easy as it was.

      • by jampola (1994582)
        Turn computer ON -> Press F12 or Del -> Disable secure boot -> Reboot

        Now THAT wasn't so hard was it?

        Yes yes, I know, some systems aren't that easy but for the last 3 or 4 (really really new) laptops I've had to install Debian on, it really was THAT easy!
  • Until it is something that allows for end-user control of the process instead of Microsoft, then the only support necessary is for it to be made non-functional.

    • Re: (Score:1, Insightful)

      by bws111 (1216812)

      Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

      • by 0123456 (636235) on Monday July 08, 2013 @08:55PM (#44221139)

        Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

        So first you say that Windows Boot doesn't prevent the end user from being in control, then you admit that it puts the vendor in control. Vendor lock-in is the whole point of Windows Boot.

        • by bws111 (1216812)

          HARDWARE vendor. As in, the hardware vendor provides a way for you to manage the keys. It has NOTHING to do with vendor lockin.

          • by epyT-R (613989)

            ..and when all hardware vendors refuse to allow user generated root keys?

            • ..and when the universe dies a heat death? Anything is possible tomorrow, Secure Boot doesn't mean that suddenly 100% of the numerous PC makers will one day suddenly ban user root keys and make their devices harder to fix in case of issues.

            • by bws111 (1216812)

              And why, exactly, would they do that? Especially server manufacturers? Your suggestion is pure FUD.

            • by sofar (317980)

              Then they will not be windows 8 certified, and may not affix a "Windows 8" WHQL sticker, or advertise their systems together with any Microsoft Logo.

        • Gah, what's it about secure boot that seems to confuse so many people?

          Currently there are zero vendors that lock out users from the signing keys since being Windows Certified needs user control of keys.

          The parent posts point is that if such a vendor shows up, vote with your wallet and feet and get a computer from another vendor.

          How is secure boot about lock-in when you can turn it off with a mouse click?

          How is it Microsoft's fault that the FOSS community is unable to come up a signing organization that OEMs

          • by Nerdfest (867930)

            The FOSS community could quite easy come up with a signing organization, but is unlikely to give computer manufacturers a discount on their OS (or charge more for it) if they don't implement it. This is admittedly just a suspicion, but it does match with the history of what has happened with things like the EEE notebooks.

          • Secure boot on ARM *prohibits* the user from modifying the signing keys or turning it off.

            • by Microlith (54737)

              To be more accurate, Microsoft's system vendor requirements for Windows 8 on ARM (Windows RT) require that it not be possible to turn off secure boot. Nothing about secure boot inherently makes it impossible to turn off. Microsoft is simply forcing their will on the OEMs who then take that control away from you.

              The best thing to do is to let Windows RT die in the market.

          • by Microlith (54737)

            How is it Microsoft's fault that the FOSS community is unable to come up a signing organization that OEMs are willing to add?

            Because it was laid out poorly from the beginning. Had the key architecture not been left up to an ad-hoc distribution mechanism and, instead, been firmly rooted in the UEFI Foundation, then said signing organization could have gone to the UEFI Foundation and gotten a key without involving Microsoft.

            Instead, it was ad-hoc and as a result anyone who wanted their key on the platforms ha

            • Because it was laid out poorly from the beginning. Had the key architecture not been left up to an ad-hoc distribution mechanism and, instead, been firmly rooted in the UEFI Foundation, then said signing organization could have gone to the UEFI Foundation and gotten a key without involving Microsoft.

              What is this UEFI Foundation that you speak of?

          • by Anonymous Coward

            Currently there are zero vendors that lock out users from the signing keys since being Windows Certified needs user control of keys.

            Maybe not, but as long as nobody can tell how to get in control of the keys, that's as good as being locked out.

            Asking Google for help just gives "You need to enter UEFI setup", with no explanation of how to do that. And none of the usual keys work (F1, F2, Esc, Del).

            Googling how to enter UEFI setup then gives a lot of pages explaining that first you need to buy Windows 8, then

      • by MrNemesis (587188)

        "...and then they came for *my* bootloader, and there were no more vendors to speak out for me."

        With apologies to Niemoller. We've already seen a whole class of devices introduced with the inability to boot anything other than their proscribed OS, we've seen the WindowsRT "our bootloader only", and we've not got "UEFI secure boot must be available, but have an off switch for people willing to go into their BIOS". Given MS and their apparently rabid desire to turn windows from a workstation platform into a g

    • by vux984 (928602)

      Until it is something that allows for end-user control of the process instead of Microsoft,

      In that the end user can remove the microsoft key? Yes, it can do that.

      In that the end user can install their own key, sign their own software, and boot from that? Yes, it can do that too.

      What exactly is your gripe?

      • by 0123456 (636235)

        In that the end user can remove the microsoft key? Yes, it can do that.

        Unless the hardware manufacturer won't let you.

        In that the end user can install their own key, sign their own software, and boot from that? Yes, it can do that too.

        Unless the hardware manufacturer won't let you.

        What exactly is your gripe?

        That the hardware manufacturer is telling me what I can and can't run on hardware I own?

        In any case, Windows Boot has an insignificant security impact on servers. If my server reboots unexpectedly to load malware, I'm sure as hell going to find out why.

        • by Rockoon (1252108) on Monday July 08, 2013 @09:09PM (#44221225)

          Unless the hardware manufacturer won't let you.

          Isn't this argument essentially fear, doubt, and uncertainty?

        • by bws111 (1216812)

          And what if the server is intentionally rebooted (by you) to install malware? Ideally the management of the keys in hardware would be protected and only performed by someone who does not have root authority to the OS. Secure boot can help stop rogue admins. It gives control to the owner of the server instead of the admin.

        • by vux984 (928602)

          Unless the hardware manufacturer won't let you.

          Which is nothing to do with secureboot, and everything to do with the hardware manufacturer.

          Hardware manufacturers have been technically able to make it so you can't go into BIOS, and have been technically able to restrict what bootloader you use since as long as BIOS has existed.

          Secureboot really has nothing to do with it one way or the other.

          That the hardware manufacturer is telling me what I can and can't run on hardware I own?

          They haven't done so in the pas

        • by murdocj (543661)

          Which hardware manufacturer?

      • by Microlith (54737)

        In that the end user can install their own key, sign their own software, and boot from that?

        Maybe. If the device you're booting from has its option rom signed by Microsoft and you remove their key, can you boot from the device anymore? My educated guess is no (you can't truly get away from Microsoft) and you are forced to trust Microsoft even if you don't want to because hardware OEMs can only ever assume one key is available due to the (poor) architecture.

        • by vux984 (928602)

          If the device you're booting from has its option rom signed by Microsoft and you remove their key, can you boot from the device anymore?

          You should also be able to authorize the option roms you need by hash.

          My educated guess is no (you can't truly get away from Microsoft) and you are forced to trust Microsoft even if you don't want to because hardware OEMs can only ever assume one key is available due to the (poor) architecture.

          This problem is at least solvable by market forces, and is not a defect in the

  • Secure Boot ISN'T! (Score:2, Insightful)

    by kawabago (551139)
    Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.
    • I think it more likely it was about Android on ARM. MS didn't want to end up selling some fantastic hardware device and getting all the 'momentum' wiped out by Android loads so people could run with a platform with some semblance of an ecosystem going (though I've not seen an RT device I'd find interesting regardless of software). x86 got to come along for the ride so that MS would be doing things in a nicely consistent fashion with more credibility on the matter of rootkit mitigation. It does mitigate r

    • by recoiledsnake (879048) on Monday July 08, 2013 @09:34PM (#44221351)

      Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

      +3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

      Can you tell us how it's easy to get around Secure Boot?

      Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers

      Here's a couple of viruses that Secure Boot prevents.

      http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection [chmag.in]

      http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk]

      http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com]

      I recommend reading atleast the first link.

      Here's one juicy bit:

      TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

      When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

      The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

      The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

      The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

      TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

      All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

      Another bit:

      The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where

      • by csumpi (2258986)

        What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

        Welcome, young Skywalker, I have been expecting you.

      • by Junta (36770)

        Can you tell us how it's easy to get around Secure Boot?

        Well, that rootkit had to go through quite a few hoops to avoid detection. A different set of hoops are in order here.

        It'd be hard to hide a MS hypervisor because they are so bloated, but a linux hypervisor can be constructed in under 24 megabytes, which is essentially a rounding error in the typical EFI boot partition as created by MS. So the rootkit is a linux bootloader, kernel, and initrd with qemu and such. The rootkit has to fake a *lot* more stuff to fool extremely comprehensive security software

        • MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning.

          And it still wouldn't protect the system from TDL4, while SecureBoot does. Your idea of how to secure the system would be broken in a matter of days, if that long for other malware.

        • The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive.

          This is where you fail. Microsoft does not sign competitor payload using a UEFI burned key. What Microsoft offers is that they will sign 2nd level boot loaders so that the Microsoft bootloader will accept to chain-load it. You cannot directly boot such a Microsoft signed bootloader or OS directly from UEFI.

          Why is this significant? Because
          1. It allows Microsofts bootload'er to make it *obvious* that a foreign OS is being booted. You cannot get around this because it is Microsofts code that gets the control b

        • by dargaud (518470)

          As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.

          Yes. I aways wondered why writing to the MBR wasn't possible only after going into BIOS, activating manually an option 'allow MBR write just for this boot', install your OS, reboot and it's secure again.

      • +3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

        The problem is that a LOT of people on Slashdot basically live on Slashdot. It's their primary tech site, and hence they surround themselves with like-minded people who believe Linux will crush Microsoft on the desktop any day now, that Microsoft are dying, that no-one could like Windows/Microsoft by choice, that most people s

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          The problem is that a LOT of people on Slashdot basically live on Slashdot. It's their primary tech site, and hence they surround themselves with like-minded people who believe Linux will crush Microsoft on the desktop any day now, that Microsoft are dying, that no-one could like Windows/Microsoft by choice, that most people support Snowdon and his actions, and so on. It's one great bit echo chamber as opinions get reinforced by other like-minded posters, which strengthens their opinions and moves them into undeniable fact.
          A place like ArsTechnica shows a vastly different situation, with far more people showing more varied opinions, such as liking Windows 8, preferring Microsoft technologies like C# to C++/Java, preferring Surface to iPad, and in this case, seeing the benefits of Secure Boot. Why do they do this? Because they aren't fucking brainwashed to believe what Slashdot tells them to believe.

          I can see what you're saying, but the Slasdot community is largely made up of REAL nerds - old school!
          We remember rebooting Windows 3.11 for workgroups more than 20 times a day due to system crashes when trying to do real work.
          We remember the amazement of playing sasteroid with no lag while installing slackware from floppies.
          We remember the shit that Microsoft has pulled over the decades to crush superior products, especially ones like Linux and Java that threatened it's vendor lock-in stranglehold.
          Fuck me

      • by Rashkae (59673)

        Interesting summary on that TDL4, thanks...

        After all this time, i still remember the good ol' days having to clean up MonkeyB... it's nice to see the old timer ideas getting put to more modern/criminal use

      • by ashpool7 (18172)

        Why do the OEMs get to add keys? Why can't I load the key myself from UEFI or another side channel?

        This is why secure boot triggers "do not want." Motherboard manufacturers are trying to wedge themselves in as gatekeepers where they were previously not.

        • Why can't I load the key myself from UEFI or another side channel?

          You can.

          http://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/ [hansenpartnership.com]

          Typical Slashdot ignorance and blind hatred.

          • by ashpool7 (18172)

            Except the OEM can prevent this from being an option for you.

            • Sure, but they will lose Windows 8 certification which gives them marketing, discounts etc.

              That's why no OEM currently prevents that option. If you have a reference stating that one does, please provide it. Until then it's just speculation, an OEM can do anything in the future, including blocking Windows from running.

              • by ashpool7 (18172)

                Sure... for x86 machines. I assume you mean

                http://technet.microsoft.com/en-us/windows/dn168167.aspx [microsoft.com]

                where they have four requirements, one of which is "They must allow the user to completely disable Secure Boot."

                Now, for the Win RT version of Surface

                http://support.microsoft.com/kb/2800988 [microsoft.com]

                "If the computer is running Windows RT, Secure Boot cannot be disabled."

                Hmmmmmmmmmmmmmm

                • Windows 8 is not the same as Windows RT.

                  Windows 8 runs on only x86.

                  I love how the iPad gets a free pass but the barely selling WindowsRT is a big deal.

                  • by ashpool7 (18172)

                    What *is* the same between the Surface Pro and the Surface (RT), is that UEFI and Secure Boot are being used.

                    Back to the original topic, this is why people do not want Secure Boot. Here is a company taking the standard and doing *exactly* what people were afraid the company would do with it. It's no longer "speculation."

                    • What *is* the same between the Surface Pro and the Surface (RT), is that UEFI and Secure Boot are being used.

                      Back to the original topic, this is why people do not want Secure Boot. Here is a company taking the standard and doing *exactly* what people were afraid the company would do with it. It's no longer "speculation."

                      Is that so? Then why can anyone run Linux on a Surface Pro?

                      Or do you mean that WindowsRT is doing so well that it will kill PCs will do more harm to user freedom than an iPad? Looks like you are more optimistic about it than MS itself!

                      If people do not want Secure Boot then why are they falling over each other to buy the iPad with a locked bootloader? Or one of the many Android phones and tablets with locked bootloaders? Or are you just speculating about "people"?

                      It's like saying Antivirus programs will one

                    • by ashpool7 (18172)

                      You're not forced to install antivirus programs nor is there a scheme to prevent you from removing them.

                      I'm not speculating about "people," I'm talking about the "people" accused of turning their brains off when Secure Boot gets brought up. These are the same people who don't like the locked bootloaders on the iPad and especially on Android phones and tablets.

                    • You're not forced to install antivirus programs nor is there a scheme to prevent you from removing them.

                      ...yet.. just like secure boot on x86 PCs.
                      Boot kits are prevalent on PCs and Secure Boot prevents it while allowing the small percentage of enthusiasts to install alternative OSes on x86.
                      Just because some person wanting to install some OS can't bothered to uncheck a checkbox doesn't mean that hundreds of millions of PC users must be subject to undetectable rootkits.

                    • by ashpool7 (18172)

                      I know you want to be like x86 != ARM, which is fair, but UEFI == UEFI

                      It would be great if you could just uncheck a checkbox at boot time, but this standard was made so that you can remove that checkbox and still claim standards compliance. That's the rub.

    • by westlake (615356)

      Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers.

      Not a problem.

      Top 7 Operating Systems From June 2012 to June 2013 [statcounter.com]. Desktop Operating System Market Share [hitslink.com], OS Platform Statistics 2003-2013 [w3schools.com]

    • Security has to constantly evolve to meet evolving problems. Hardware can't do that.

      Is that really true? Firmware can be updated. Hardware components that can be read during system initialization can be added. There are at least some possibilities.

  • Secure Boot is just another attempt by Microsoft to maintain their near monopoly on computer operating systems. They are failing to compete, severely, so have no choice but to find some method that will force people to continue to be blessed by Microsoft before being free to use the devices they purchased. Take the planned new XBox as an example of their obsession with control.

    As much as I respected Nokia for their hardware manufacturing prowess, I have to admit I am a cheerleader for their demise as the p

    • Search for "unlocked cellphone with hardware keyboard" and you will understand the problem.

      Couldn't it be solved by making a case with a slide-out Bluetooth keyboard? Google tells me that such cases exist for iPhone 4/4S and Galaxy S3; I don't know if any single chassis shape for any other model has enough market share to merit making a compatible case.

    • They are failing to compete, severely

      I agree. Microsoft should have done something long before Linux hit 0.97% marketshare.

  • From my perspective, securing the boot loader is the first step. Then you need a binary checker (which has been around for a while), and a trusted vendor distributing the updates and binary checksums. With those two pieces in place, you can at least have some modicum of insurance that your binaries haven't been compromised since they were released by the vendor.

    I wouldn't worry about custom executables, though -- how is a hacker supposed to even know they exist unless they've got inside info on your co

  • MS lock in is bad when they have an app store and may try to make it app store only / kill off all of the older apps.

    Also why code for metro when you can code that will run on windows , mac and Linux.

  • Microsoft only endorses SUSE because Novell/Attachmate pays them off for the patents that they've allegedly infringed.
  • I understand the software writers don't want to marginalize themselves in case servers adopt UEFI. However, there are zero security benefits of UEFI, versus booting part of your OS right from the BIOS/Firmware. It's up to the OS's bootloader to kick of an encryption chain after UEFI loads. So, put the damn bootloader in the firmware with Coreboot. [coreboot.org]

    The way my setup works is that Coreboot has a bootstrap loader for my OS in firmware. The BIOS requrires a password to access it, and enable the flashing of firmware. Type password, "Enable Firmware Flash On Next Boot" option. No screwy hex code you're bound to mess up several times. My boot protocol uses public key crptography so that the custom multi-boot loader can handle any number of OS updates. The 2nd stage OS loader changes, it can include the signature of via key that's paired with the OS's 1st stage firmware boot loader. DONE. All we need is a standardized way for BIOS to flash a small part of the OS loader at OS install, and then any OS can be just as secure as secure boot, without ANY hierarchy of control -- The OS devs can own all the keys they use to secure and load their own OS. It's not like the chips don't have the memory now -- Shit, on new desktop systems the firmware has gaudy graphics, animations, and sounds -- The damn motherboard runs a stipped down Linux or BSD to prestent you the BIOS config options!

    So, think about this. Coreboot + Key/Signing you already have to have in the OS loader is just as secure as UEFI, except there's no grand central Microsoft authority who says what OS can and can not install on the hardware, or to pressure hardware makers into bowing to the demands of the Windows requirements. If there is a bug in the BIOS or hardware that lets it rewrite firmware from software without permission, then it exploits UEFI or Coreboot equally -- How do you think UEFI is implemented -- IN FIRMWARE? Hell, I have the option with Coreboot to use UEFI boot if I want. However, I can also remove that shite, or even have the firmware setup legacy BIOS interrupt tables for booting old OS's like MSDOS, DR DOS, etc. Currently, I have my system config in my Coreboot, so it doesn't search for shit, just loads my OS and runs instantly at power up.
    Coreboot w/ OS + SSD = Milliseconds to boot; Beat that, Security Theater Boot.

    They should rename that shite, Microsoft Controlled Boot, because it is, for all intents and purposes. Stop and think. How can a sysop like me figure out a more flexible system that's just as secure as SecureBoot, more easy to use and maintain, and even adds security to tons of legacy x86 hardware -- Yet all those well paid folks who's only job was to engineer a secure boot standard "UEFI", came up with some restrictive shit that in effect gives Microsoft more control of the hardware and software arena? NO. ACTUALLY THINK. SEE?

  • The big question which the original article doesn't address is:

    Does SuSE expect the owner of the machine to specify the top-level signing keys? Or does it expect Microsoft's to be frozen into the hardware?

  • As a number of valid questions have been asked here, I'd like to point you to details about our approach:

    (1) https://www.suse.com/communities/conversations/uefi-secure-boot-overview/ [suse.com]
    (2) https://www.suse.com/communities/conversations/uefi-secure-boot-plan/ [suse.com]
    (3) https://www.suse.com/communities/conversations/uefi-secure-boot-details/ [suse.com]

    Those blogs have been published around the time when we had decided to implement UEFI Secure Boot in SUSE Linux Enterprise 11 SP3. For those who like to understand things visually,

Technology is dominated by those who manage what they do not understand.

Working...