Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Security Microsoft Operating Systems Linux

Linux Foundation Offers Solution for UEFI Secure Boot 308

Ever since news broke last year that Microsoft would require Windows 8 machines to have UEFI secure boot enabled, there were concerns that it would be used to block the installation of other operating systems, such as Linux distributions. Now, reader dgharmon sends this quote from Ars Technica about a new defense against that outcome: "The Linux Foundation has announced plans to provide a general purpose solution suitable for use by Linux and other non-Microsoft operating systems. The group has produced a minimal bootloader that won't boot any operating system directly. Instead, it will transfer control to any other bootloader — signed or unsigned — so that can boot an operating system." The announcement adds, "The pre-bootloader will employ a 'present user'; test to ensure that it cannot be used as a vector for any type of UEFI malware to target secure systems. This pre-bootloader can be used either to boot a CD/DVD installer or LiveCD distribution or even boot an installed operating system in secure mode for any distribution that chooses to use it."
This discussion has been archived. No new comments can be posted.

Linux Foundation Offers Solution for UEFI Secure Boot

Comments Filter:
  • Exactly. Malware authors can use this. So we've come full-circle and only gained a big heap of complexity. Which is the best we could hope for once this idiotic idea got going.

  • by Chrisq ( 894406 ) on Friday October 12, 2012 @08:37AM (#41630189)
    From TFA:

    To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots. In this way, it can't be silently installed and used to hand control to a rootkit without the user's knowledge

    Doesn't this mean it is unsuitable for server use - or any "headless" operation such as MythTV?

  • Re:Virtualization (Score:5, Interesting)

    by afidel ( 530433 ) on Friday October 12, 2012 @08:47AM (#41630355)

    Windows 8 doesn't require SecureBoot, otherwise their enterprise adoption would be 0% instead of the likely 1-5%. Windows 8/Server 2012 works under ESXi 5.0 with patches and is supported under 5.1.

  • by GameboyRMH ( 1153867 ) < minus cat> on Friday October 12, 2012 @08:49AM (#41630401) Journal

    Apple is attacking the consumer's expectation of software freedom. You can't go any lower that that without a brain implant.

  • by ByOhTek ( 1181381 ) on Friday October 12, 2012 @08:54AM (#41630485) Journal

    I think it's worse than that.

    Apple is building /their/ product and trying to get everyone to adapt their needs to it. At least MS is trying to make it's product general purpose (if ineptly in some cases), and allow people to have options at every level except the OS. Apple tries to restrict options at ALL levels.

  • They didn't seem to have any problem setting up boot sector viruses without UEFI secure boot, so if they can get a signed bootloader, why should they now? And signing the startup chain will remove even MORE user freedoms, it's a chicken-and-egg problem that won't end until the OS is at least as locked down as iOS.

  • by 3seas ( 184403 ) on Friday October 12, 2012 @09:06AM (#41630681) Homepage Journal

    If we make it, we can break it. Making secure boot just more locks to keep honest people out and more headaches for honest people to deal with.

    Perhaps the real question here is why do people continue with Windows, when there are other options that have better general security?

  • And what will the average noob user do? Hit Enter to use their computer or use a Windows recovery disk* to fix the bootloader? And if they do hit Enter and the computer apparently works fine, what do you think they'll do then?

    *Not sold with many PCs, must be burned from the hard disk

  • by erikvcl ( 43470 ) on Friday October 12, 2012 @09:15AM (#41630827) Homepage

    Why are you fighting secure boot? Secure boot is a GOOD thing. Making sure your BIOS/UEFI and boot loader haven't been tampered with is a GOOD thing. Let's figure a good way to make Linux work with it. I'm glad that Microsoft is taking this attack vector seriously.

  • by smittyoneeach ( 243267 ) * on Friday October 12, 2012 @09:16AM (#41630837) Homepage Journal
    If you've got a closed system of bits, then enough time, hardware, and interest should yield a way to jailbreak it.
    So the real value would seem to be found in upping the time, hardware, and interest requirements.
    What could well happen is that, in making Windows really painful to integrate with other systems, Redmond kills their sales.
    And wouldn't that just suck Puget Sound dry?
  • by swm ( 171547 ) * <> on Friday October 12, 2012 @09:30AM (#41631035) Homepage

    the Linux Foundation will obtain a Microsoft Key and sign a small pre-bootloader which will, in turn, chain load (without any form of signature check) a predesignated boot loader which will, in turn, boot Linux (or any other operating system).

    The purpose of Secure Boot is to prevent people from booting non-Microsoft operating systems.
    Why on earth would Microsoft sign such a bootloader?

    The process of obtaining a Microsoft signature will take a while, [...]

    Anyone want to open an over/under line on when this happens?
    I'll put $100 on the first patch Tuesday following the heat death of the universe.

  • by marcello_dl ( 667940 ) on Friday October 12, 2012 @09:47AM (#41631281) Homepage Journal

    Do you really think that the makers of an operating system which requires 3rd party AV to correct its own security shortcomings devised secure boot to protect users from malware?

    For most corporations dealing with IT, your PC, smartphone, electronic device is "territory" to be owned as much exclusively as possible.

    Secure boot has been a FUD operation on free OSes, nothing more.
    I repeat it again, If you want to secure the bios put a jumper before the write pin of the eprom/flash memory/whatever. Those who can't open the case and locate it are surely not qualified for a bios upgrade.
    I made one firmware upgrade in the last 15 years on my machines, and that upgrade was necessary only if I wanted 64bit linux.

  • by jader3rd ( 2222716 ) on Friday October 12, 2012 @09:52AM (#41631339)

    One huge difference between Apple and Microsoft is that nearly nobody is forced to buy or use Apple products

    Okay, so what happens when millions (billions?) of persons use OS X and iTunes because they have to (company policy) or because they need to product iWhatever documents? Would you rather live in the Apple "Cupertino controls your entire experience" world or the "Build on top of our platforms to do what you want, just don't muck directly with the licensed software" world of Microsoft?

  • by cpghost ( 719344 ) on Friday October 12, 2012 @10:06AM (#41631513) Homepage

    That seems like a LOT more of a pain in the butt than simply turning off the secure boot option.

    How long will motherboard BIOSes ship with the option to turn off UEFI secure boot? Maybe not tomorrow, but what about 1, 2 or 3 years down the road? That's the real issue here! The problem is that the PC commodity market is about to be turned into a walled garden controlled by, guess who? Microsoft in this case. That's pretty scary stuff actually, and I wouldn't wonder if the regulating authorities (at least in the EU) will sooner or later consider this as anti-competitive behavior.

  • by recoiledsnake ( 879048 ) on Friday October 12, 2012 @10:23AM (#41631723)

    Here we go with the hyperbolics without even RTFA'ing. You can choose to install the key in the store when UEFI is in setup mode so that you don't see the prompt again. []

    Or just fricking turn off secure boot.

  • by DRJlaw ( 946416 ) on Friday October 12, 2012 @10:40AM (#41631979)

    And I'd be really fucking pissed off if my Linux PC required a user present at the console to reboot. Seriously, how is this a fix?

    Because it is a fix for those who cannot or will not use the alternative of entering their own list of acceptable signing keys into the UEFI, which would not require a user present but draws a great hue and cry that it is "too complex" for the average Linux user to accomplish.

    1. Enter your keys into the UEFI key list, walk away; or
    2. Have a user present to acknowledge that they want to boot unsigned/signed-but-not-entered code; or
    3. Don't use a UEFI PC; but not
    4. Prevent the rest of the world from having access to a secure boot chain because you refuse to lift a finger yourself

  • by mystikkman ( 1487801 ) on Friday October 12, 2012 @10:47AM (#41632067)

    Do you really think that the makers of an operating system which requires 3rd party AV to correct its own security shortcomings devised secure boot to protect users from malware?

    You mean the Linux folks designed UEFI Secure boot? []

    I repeat it again, If you want to secure the bios put a jumper before the write pin of the eprom/flash memory/whatever. Those who can't open the case and locate it are surely not qualified for a bios upgrade.
    I made one firmware upgrade in the last 15 years on my machines, and that upgrade was necessary only if I wanted 64bit linux.

    Secure boot is not about the BIOS, it is about bootkits. You don't know what you're talking about and still get modded +4 interesting, typical Slashdot, really. See below for an example.

    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 it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.

  • by mea_culpa ( 145339 ) on Friday October 12, 2012 @03:09PM (#41634879)

    You are assuming that BIOS settings will be user accessible in the future.

"Here at the Phone Company, we serve all kinds of people; from Presidents and Kings to the scum of the earth ..."