Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
SuSE DRM Operating Systems Linux

SUSE Slowly Shows UEFI Secure Boot Plan 190

Posted by Soulskill
from the at-a-stately-and-majestic-pace dept.
itwbennett writes "One blog post at a time, SUSE is revealing its plan for getting SUSE Linux Enterprise Server (SLES) to boot on machines with UEFI Secure Boot. The short version: 'For now, it seems, SLES will implement an approach similar to that used by Fedora,' writes Brian Proffitt. '[Director of the SUSE Linux Enterprise Olaf] Kirch's first blog entry on Tuesday merely introduced the problem of UEFI Secure Boot. Today's blog only specified the use of the shim bootloader.' Just dying to know what's next? Tune in to the SUSE blog."
This discussion has been archived. No new comments can be posted.

SUSE Slowly Shows UEFI Secure Boot Plan

Comments Filter:
  • by Anonymous Coward on Wednesday August 08, 2012 @06:20PM (#40924501)

    I'm used to a little bit of healthy paranoia here, but the amount of FUD and flat-out misinformation in Slashdot's UEFI reporting is frankly astonishing. Let's get a few things straight.

    UEFI is not a Microsoft technology. It is an industry standard intended intended to replace the archaic x86 BIOS. Microsoft participated in the standard, as did Slashdot favorites Red Hat, Canonical, IBM, and AMD. You can freely download the full specification [uefi.org] from the uefi.org website.

    Secure Boot is part of the larger UEFI specification. See section 27 for the technical details. Of particular interest to Slashdot readers will be section 27.7 which describes the key update mechanism.

    Secure Boot is intended to solve the real-world security problem of boot-time malware. No operating system can defend against malware at boot-time; this would be equivalent to defending against the hardware itself. If it helps, imagine how you would defeat a keylogger embedded in your keyboard.

    Secure Boot uses code-signing to defeat boot-time malware. This is the optimal solution and should be full-proof provided (1) the machine is physically secured, and (2) the private keys are secure. (I am defining "full-proof" here to mean the keys and hashes involved are adequately difficuly to brute-force with modern hardware. I am also explicitly discounting scenarios outside of UEFI's area-of-responsibility, such as vulnerabilities in the operating system's signed image.)

    For some real irony, see the Slashdot article Windows 8 Secure Boot Defeated [slashdot.org]. Both the headline and much of the discussion in this article were flat-out wrong. The exploit in question targetted the legacy BIOS and MBR. This is exactly the problem that Secure Boot addresses, and it reinforces the need for this technology.

    Secure Boot is not a DRM scheme, nor it is explicitly a tool for Microsoft lock-in. Remember that on x86 platforms, the end-user can edit the key database, and can disable Secure Boot entirely. I concur that Microsoft's treatment of ARM is a dick move, but is also typical for other vendors in that market segment. In either case, remember that Secure Boot is a logical solution to a real-world problem affecting all operating systems, and evaluate it on this merit first.

    Just because the technology can be mis-used is no reason to completely boycott it. For my part, I intend to use Secure Boot when it becomes generally available, but only buy parts that allow me to edit the key database.

    Links:
    UEFI membership list: http://www.uefi.org/join/list/ [uefi.org]
    UEFI specification: http://www.uefi.org/specs/agreement [uefi.org]

  • by Anonymous Coward on Wednesday August 08, 2012 @07:43PM (#40925463)
    Only for ARM based systems. Microsoft has stated that all Windows 8 branded x86 PCs must have the ability to disable secure boot.
  • by phantomfive (622387) on Wednesday August 08, 2012 @09:58PM (#40926611) Journal
    As someone who's gotten Linux to boot on an EFI machine, I can tell you that motherboards do not always implement the full specification.

    Generally they do what is necessary to boot Windows, and once that's working, call it good. They have no motivation to test and make sure disabling UEFI works.

Possessions increase to fill the space available for their storage. -- Ryan

Working...