Announcement

Collapse
No announcement yet.

Ubuntu's Plans To Implement UEFI SecureBoot: No GRUB2

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by Kano View Post
    And what do you think about the idea just to sign the bootloader? Is there any reason why nobody else should use the same bootloader to boot custom code?
    Follow up on this - there was some discussion of it by Matthew and Peter, and ajax, on the fedora-devel list yesterday:

    https://lists.fedoraproject.org/pipe...ne/169341.html (the initial question about Ubuntu's approach)

    https://lists.fedoraproject.org/pipe...ne/169353.html
    https://lists.fedoraproject.org/pipe...ne/169362.html
    https://lists.fedoraproject.org/pipe...ne/169350.html

    To summarize - there is considerable scepticism that any approach which doesn't actually make a reasonable attempt to restrict what can be booted using a signed bootloader chain will be viable. Our guys pretty much reckon that if Canonical does go ahead with the plan to just get a generic bootloader signed in such a way that anyone could boot anything with it, that will be revoked quite quickly, or never signed in the first place. I particularly like ajax's take on it - anything formulated as a Futurama quote gets an automatic +10 from me.

    edit: my disclaimer about being entirely prepared to be wrong in any situation still applies. The above is only my interpretation of other people's responses to canonical's plans; there are zillions of possible points of failure there, and I certainly don't mean to be read as stating categorically that Canonical's plans are flawed. the people who signed https://lists.ubuntu.com/archives/ub...ne/035445.html are certainly smart cookies who, like matthew and peter, probably know much more about this than me. So don't put too much weight on anything I say when it comes into conflict with any of those. I'm sure we'll find out down the road how everything shakes out.
    Last edited by AdamW; 06-26-2012, 03:09 PM.

    Comment


    • #77
      Originally posted by aliasbody View Post
      Personally I think that the real problem is the Secure Boot itself. The need for a key ?.. Why not... The need for a payed key ? That's the stupidiest thinkg I ever heard. What about the liberty of doing with the PC whatever we want ? But let just pass that..

      The option to disable the Security Boot on the BIOS is a good idea, but it is not the solution. For example, Ubuntu had to buy a key and introduce it on the new Ubuntu in order to new users that don't understand well computers and just bought one with UEFI and Secure Boot Active could boot Ubuntu without blamming it for not working and not understanding why.

      And, It is already a pain in the a** (sorry for the expression), to find a computer without Windows in stores, but now if we have to handle with computers with probably a Metro visual in the UEFI (I heard of that a long time a go so I don't know if the situation changed), and a Secure Boot with the possibility to not desactivate that could be a really mess.

      I am not blaming Microsoft, I just don't understand the whole situation at all...

      If disabling Secure Boot is not the solution, then what is?

      This whole OS-signing, driver-signing and kernel module signing things may sound new for users of alternative operating systems but the reality is that they are things that Windows users have come to take for granted today. Ever since Microsoft released Windows XP Profesional (64bit edition) driver and module signing has been mandatory for any hardware vendor who makes peripherals for the dominant operating system. While you can drive a bus through the numerous security holes present in the 32-bit version of Windows XP, the same cannot be said for XP 64-bit and its successors, Vista and Win 7. Sure they do have their own set of flaws but malware entering the system via compromised drivers are largely unheard of nowadays.

      Now, let's assume that Microsoft's harsh stance on mandating driver signing is successful in eliminating the threat of rogue drivers being used as a vehicle for malware to attack the operating system. Logically, the next aspect of Windows Microsoft will want to secure is the boot process, because malware can easily bypass a variety of safeguards if it is able to inject itself into the Windows booting process. Since most motherboard and notebooks that are being sold in the past 2 - 3 years are now UEFI capable, and the UEFI specification provides for an un-utilized feature known as Secure Boot that is reportedly capable of safeguarding the boot process from malware, it makes sense that Microsoft will want to make full use of it, if only so that it can save on R&D costs in figuring out how to do the same thing should Secure Boot not exist.

      Think about it: Secure Boot safeguarding the boot process + running Windows with a Limited account and UAC enabled + mandatory driver signing means that the number of attack vectors malware can strike at Windows is significantly reduced.

      And I don't believe for 1 second any conspiracy theories claiming that Microsoft cooked up Secure Boot just to lock users out from installing alternative operating systems. The fact that it has the unintended consequence of actually doing so is just a bonus for Redmond; remember that Microsoft makes money selling its operating systems.IF we assume that Windows 8 does not do well on launch, people are going to buy Windows 7 DVDs (or pirate, if they have no respect of copyright or proprietary intellectual property) and downgrade their Windows 8 installation to Windows 7. And if Secure Boot is too draconian, downgrading to Windows 7 will be impossible and Microsoft will lose money from potential Windows 7 sales, not to mention that it will garner considerable ill will from its customers (do not forget that Microsoft provides downgrade clauses in its contract with OEMs for certain licenses), hence the requirement that any x86 computer sold with Windows (which is virtually 99% of all non-Apple OEMs) must feature some option to disable Secure Boot so that the downgrade can take place.

      In the end, Microsoft is just covering its bases to ensure that its CUSTOMERS can do what they want with their x86 computers, and that its hardware partners can offer WINDOWS USERS a choice where Secure Boot is concerned. Leave Secure Boot on and run Windows 8, or disable it and downgrade to Windows 7, it's their choice. Linux users were never part of Microsoft's customer base, so as cynical as it may sound, Microsoft has no obligation to cater to them.

      Anti-competitive? Definitely not; they are not putting a gun to your head and demanding that you use Windows. And indeed, with Secure Boot disabled, a user can install virtually any operating system he/she desires on his/her computer. But if it makes you feel better, you can blame Microsoft for being a dick and needlessly accelerating the adoption of an established but unused specification.

      *Don't bother bringing in Windows 8 tablets into the discussion; there's a very good reason these are locked with no chance to disable Secure Boot. You can thank (or curse) Apple and Google (Android) and the non-universal/standardized nature of ARM hardware for setting the precedents in locked-down tablet computing.
      Last edited by Sonadow; 07-09-2012, 01:08 PM.

      Comment


      • #78
        Originally posted by aliasbody View Post
        And, It is already a pain in the a** (sorry for the expression), to find a computer without Windows in stores, but now if we have to handle with computers with probably a Metro visual in the UEFI (I heard of that a long time a go so I don't know if the situation changed), and a Secure Boot with the possibility to not desactivate that could be a really mess.
        As ironical it may sound, but if you have to buy a computer with Windows (thank Bob that we don't need to do that here in Germany) then you should look around and only buy hardware with Windows 8 logo. One of the requirements for getting the Windows 8 logo for x86 hardware is that there has to be the possibility to disable Secure Boot and also the possibility for the end user to add own custom keys.

        Comment


        • #79
          I saw this linked from groklaw.net, it is secureboot in practice: https://plus.google.com/112648813199...ts/Z2ntB81QEG4.

          Comment


          • #80
            Sorry about the double post, but it was too late to edit the other one. Here is a English language article about it: http://www.h-online.com/open/news/it...t-1635893.html.

            Comment


            • #81
              Originally posted by Kristian Joensen View Post
              Sorry about the double post, but it was too late to edit the other one. Here is a English language article about it: http://www.h-online.com/open/news/it...t-1635893.html.
              Well!

              If every single board manufacturer will have such a comprehensive menu for managing the UEFI Secure Boot feature I say this is essentially a complete non-issue already. Just delete the keys and we're good to go with the machine back to being a complete blank slate.

              Keyword being 'IF'.

              Comment


              • #82
                Originally posted by Sonadow View Post
                Well!

                If every single board manufacturer will have such a comprehensive menu for managing the UEFI Secure Boot feature I say this is essentially a complete non-issue already. Just delete the keys and we're good to go with the machine back to being a complete blank slate.

                Keyword being 'IF'.
                Well this is the implementation by American Megatrends Incorporated (AMI).
                So I guess it will look pretty much same on all motherboard vendors and OEM who use that, unless for some reason they remove that.

                Also, we're yet to see if Phoenix Technologies (AwardBIOS) implements it like this too.

                Then there is Insyde BIOS though, but its less commonly used, I believe. I don't know if Insyde have any UEFI solution, but I can guess they do.

                Comment


                • #83
                  It is so uncommon that the very small company asus uses Insyde - btw. i just found a new bug in it. Using the 3402 firmware version for my p8z68-v board boot entries are removed with the same filename (efibootmgr -l option) - it does not matter if the label or the options used are different. only the last entry is kept. a bit stupid when you want to use differnt boot options but the same kernel. i filled out a support form but did not yet get a response... if somebody wants to verify that with a newer board let me know.
                  Last edited by Kano; 07-11-2012, 09:20 AM.

                  Comment


                  • #84
                    Originally posted by Kristian Joensen View Post
                    I saw this linked from groklaw.net, it is secureboot in practice: https://plus.google.com/112648813199...ts/Z2ntB81QEG4.
                    Interesting. Clearly not the type of implementation we'll see on Win8 machines, though, as it defaults to off and no Microsoft key is enrolled. Thanks for the catch! I don't follow Google+.

                    Comment


                    • #85
                      Originally posted by uid313 View Post
                      Well this is the implementation by American Megatrends Incorporated (AMI).
                      So I guess it will look pretty much same on all motherboard vendors and OEM who use that, unless for some reason they remove that.

                      Also, we're yet to see if Phoenix Technologies (AwardBIOS) implements it like this too.

                      Then there is Insyde BIOS though, but its less commonly used, I believe. I don't know if Insyde have any UEFI solution, but I can guess they do.
                      I have a weird Insyde firmware on my Sony laptop. It's actually a UEFI firmware but it _only_ allows you to use BIOS emulation; you can't force it to do a native UEFI install of anything, it just won't. Oddness. That's a couple years old, though.

                      Comment


                      • #86
                        Originally posted by Sonadow View Post
                        Well!

                        If every single board manufacturer will have such a comprehensive menu for managing the UEFI Secure Boot feature I say this is essentially a complete non-issue already. Just delete the keys and we're good to go with the machine back to being a complete blank slate.

                        Keyword being 'IF'.
                        The Windows 8 certification requirements explicitly require that there be a simple toggle for turning Secure Boot off. In practice, it's _not_ going to be a problem at all on Windows 8 systems for anyone comfortable with going into firmware config screens. They'll all have an 'off' switch.

                        The requirements also say that the user must be able to manage keys, to some extent, but the requirement is written in a pretty odd way that would be compatible with some really dumb implementations. So I'm sure we'll see some.

                        Here's the full text, if anyone's interested. 17 is the requirement that user must be able to manage keys. 18 is the requirement that user must be able to disable secure boot. See http://msdn.microsoft.com/en-us/libr...dware/jj128256 .

                        17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

                        * It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

                        * If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

                        * The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

                        18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

                        Comment


                        • #87
                          Well thats known for long time. Just add instructions on your website how to disable Secure Boot and forget about it?

                          Comment


                          • #88
                            Originally posted by Kano View Post
                            Well thats known for long time. Just add instructions on your website how to disable Secure Boot and forget about it?
                            Kano: known to us, maybe, but it's painfully clear from (to a lesser extent) this thread and (to a greater extent) others I've seen lately that lots of people don't know about it at all...

                            There've been three problems identified with the 'document it and forget it' approach so far:

                            1) Some people just aren't comfortable fiddling in the firmware config _at all_
                            2) Some people might be okay with that, but not with disabling a function with 'Secure' in its name. 'Why do I have to turn off security to install Linux? Is Linux insecure?'
                            3) 'Documenting it' is likely to be rather harder to do than it is to suggest, going on the history of firmware configuration interfaces - OEMs seem to delight in customizing their firmware config interfaces for no readily apparent benefit. Even though there's only four or five major firmware vendors who all the OEMs contract their firmware implementations out to, the OEMs retain the right to request a customized user interface, and they often do. You can buy five systems with Award firmwares - from the same vendor, even - and get five different interfaces. Sadly, we won't just be able to stick one or two step-by-steps on a Wiki page and call it good. We'll probably have to print hundreds of the damn things. For experienced firmware twiddlers we can just give vague instructions - 'find the Secure Boot setting and turn it off' - but that's not enough for many. We could tell people to read the motherboard manual, but...yeah, I don't think I need to explain the problems with that. =)

                            Comment


                            • #89
                              What you say is definitely WRONG for most OEM boxes, only those you can get preinstalled with Win8. There the gui is usually limited to a minimum of options and it should be straight forward to find the needed settings. Did you really look into oem setups? You can setup basically no advanced option at all. If you document that you have to disable Secure Boot then it should be really enough. Those ppl who want to use Linux know that term for over 6 months now, you talk about full noobs only. I did never see an OEM system with graphical setup, did you? Guess why? Because it is not used in marketing like it is for retail motherboards for overclockers. There they add "simple" overclocking features even in the basic setup. Use a slider to enable overclocking, done. But those boards will not enable Secure Boot by default, you can not even buy one with UEFI 2.3.1 support when you forget about the outdated s1156 board from Intel which has got a development kit for it.

                              Comment

                              Working...
                              X