Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Microsoft Operating Systems Security Unix Windows BSD

FreeBSD Team Begins Work On Booting On UEFI-Enabled Systems 248

An anonymous reader writes "The FreeBSD project has begun the process of making it possible for the operating system to run alongside Windows 8 on a computer which has secure boot enabled." Linux distros have taken to using a minimal loader, signed by Microsoft, to enable booting on UEFI systems with secure boot. "Indeed we will likely take the Linux shim loader, put our own key in it, and then ask Microsoft to sign it," says developer Marshall McKusick in the linked IT Wire article. "Since Microsoft will have already vetted the shim loader code, we hope that there will be little trouble getting them to sign our version for us."
This discussion has been archived. No new comments can be posted.

FreeBSD Team Begins Work On Booting On UEFI-Enabled Systems

Comments Filter:
  • Well I'll be... (Score:3, Informative)

    by fustakrakich ( 1673220 ) on Monday July 01, 2013 @12:59AM (#44151299) Journal

    I did not know Microsoft won that battle.

    • by kthreadd ( 1558445 ) on Monday July 01, 2013 @01:03AM (#44151309)

      Won what battle? There is no battle. They just managed to get their key into the hardware manufacturers and happen to conveniently sell access to that. Nothing stops anyone else from doing the same.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        Hahahahaha. The rich and poor are equally prohibited from sleeping under bridges... Free-market ideology induced brain damage at its best. Or was this sarcasm? Then I am sorry.

        • Well that's how the CA business work; just that in this case it's about hardware manufacturers, not browser/OS vendors. I don't think it's a good idea from a security perspective since it trusts things by default, and can have really bad consequences when a CA is compromised. But that's how it work for now.

      • How much is M$ charging for access to that?
    • by gl4ss ( 559668 )

      I did not know Microsoft won that battle.

      well.. won and won.. they kind of lost if they had to start accepting shim loaders. kind of defeats the whole point.

      • For now.

        They dont 'have' to accept shim loaders. They are doing so for now, to minimise the backlash. There's no assurance they'll continue to do so in future, or (more likely) that they won't start imposing onerous requirements in the name of 'security' like mandating that any qualifying bootloader be incapable of loading an OS that allows unsigned drivers.

      • by jbolden ( 176878 )

        Microsoft wants to stop root kits. They want to be able to offer secure environments for DRM content. Microsoft doesn't care about people who want to boot Linux at all. So they are fine signing those because that customer base will self support on root kits. Where is the conflict? That only defeats the point if you start by assuming that Microsoft was lying about their intentions. If you start by assuming that everyone was telling the truth and there is no big conspiracy then it is perfectly fine.

  • who dont have or build motherboards that can disable EUFI. Seems to me like there's a great market for non EUFI mother boards that can target Linux/Unix users.

    • Well you can just turn the feature off, if your board has it and it happens to be turned on.

    • Comment removed based on user account deletion
      • by Anonymous Coward on Monday July 01, 2013 @01:57AM (#44151473)

        Conceptually, if the user has access physical access to the computer and the ability to plug shit in, your security is already gone.

        Conceptually, 99.99% of computer users don't even need this kind of security in the first place, so why is it being forced on 100% of the new computers?

        Conceptually UEFI won't stop a single virus which 100% of computer users face daily, and that IS a problem.

        UEFI serves one and only one purpose. It makes it 'easier' to just continue using Windows and more difficult to use any other system.

        Linux doesn't need UEFI. Nobody needs UEFI.

        Stopped shilling lipstick on a pig.

        • Replace "UEFI" with "Secure Boot" (there is a difference... EFI alone is not a major problem) and I agree 100% with you. While I'm not so sure UEFI is much better than the BIOS aside from a few limits lifted, the real problem is Microsoft's Secure Boot, which is an optional part of UEFI and being forced onto all ARM machines (thanks dicks, I mean Microsoft). Eventually, it will probably make its way to anything else Windows touches with no way to turn it off (x86?).

        • Nobody needs UEFI

          That's bullshit. I need UEFI. BIOS only allows a very limited set of space (384K) for hardware device BIOSes. I've hit that limit, as does most server admins because high performance devices use that space up very quickly. There is numerous other advantages to UEFI, but you'd need to take off your tin foil hat and actually learn about it for you to understand it. That or build a server. Then you'll be crying about why stuff doesn't work and how stupid BIOS really is and why there isn't something bette

      • Conceptually would be for secure locations that normal PC access is restricted, and do not want uncontrolled software booted to bypass their existing OS security, gaining access to the network and so fourth.

        Well, good luck with your rescue CD if it doesn't boot!

        Conceptually, the purpose of secure boot is to keep unwanted operating system software secure from the user (rather than keeping the user safe from malicious software) and preserve a quasi-monopoly for Microsoft. Hopfeully, there will be EU rulings that prohibit current practise.

    • by Arker ( 91948 ) on Monday July 01, 2013 @01:28AM (#44151397) Homepage

      It's UEFI, the Unified Extensible Firmware interface. EUFI is ExtraUterine Fetal Incubation. Very different things.

      The motherboards they are shipping now have a simple disable. So there is no immediate fear of being unable to run Linux on the things. BUT you have to go in and disable it in BIOS which is just completely over the head of most computer users these days. You dont have to make it impossible to deter most people from using it, just a tiny hurdle will divert the herd.

      Right now they are signing the certificates without a problem. But what will they do in a year or five or a decade? Building a business that relies on getting certs signed by MS doesnt seem wise long term. Of course no one thinks long term anymore... a small change in the law here, an easily fabricated incident using a signed bootloader to compromise a business there, and they could easily revoke these keys.

      The other problem is that UEFI is actually really cool tech, we dont want to get rid of it. We want to be able to use it. I should be able to install my own key on my own motherboard so it will only load code that I sign personally. Rather than simply trusting MicroSoft or turning off a great security component that I already paid for and theoretically own.

      • by devent ( 1627873 )

        I do. I am not find UEFI a "cool tech". I find UEFI the same as the old BIOS: totally useless.
        When a computer starts it should just bring up the very basic stuff and then handle the boot process to the Operating System. Nothing more. The computer should stay in a state of the BIOS for about 500ms (the quicker the better) after that the Kernel of the System takes over.

        Please tell me what I get with UEFI what the current Linux Kernel does not offer.

    • by SuricouRaven ( 1897204 ) on Monday July 01, 2013 @04:25AM (#44151939)

      Just to clarify: UEFI is not the problem. It's just a replacement for the old BIOS system which addresses the decades of accumulated legacy bodging that is the PC. Secure Boot is a feature that UEFI enables. You can have UEFI without Secure Boot.

      • by devent ( 1627873 )

        Or you can have a BIOS that addresses the decades of accumulated legacy bodging that is the PC, without UEFI.
        Just put a BIOS that removes all the old cruft of the old BIOS, adds some new features, but is totally minimalistic.

        Because in 10 or 20 years UEFI will be like the old BIOS. It will do totally old stuff that nobody wants, and it will not allow new stuff, because of the same reasons of the that the old BIOS have.

        The only remedy is to have a totally minimalistic BIOS that puts control as fast as possib

        • by gman003 ( 1693318 ) on Monday July 01, 2013 @09:20AM (#44153667)

          Or you can have a BIOS that addresses the decades of accumulated legacy bodging that is the PC, without UEFI.
          Just put a BIOS that removes all the old cruft of the old BIOS, adds some new features, but is totally minimalistic.

          That's what UEFI is - it drops old cruft (mainly ISA, AGP and such, IIRC), ups the minimum requirements (UEFI can assume some level of graphics support, so no more MDA text mode; likewise, it no longer runs in 16-bit mode), and extends functionality (booting off 2TB+ drives). They broke compatibility in a few places, but they did so, in part, to speed up boot times by moving functionality from the BIOS/UEFI to the OS.

          UEFI, itself, is a big step forward. The only problem is the "Secure Boot", and honestly, the problem is currently theoretical (at least on x86 - ARM is a different story). Secure Boot itself is fine - as long as the user is allowed to add and remove keys, and can enable/disable it, it's at worst unneeded functionality.

          • UEFI can assume some level of graphics support, so no more MDA text mode

            No it can't. Servers will still be restricted to text mode, because out-of-band management is commonly through IPMIv2, which supports text only, not graphics.

            It's ironic that Microsoft is getting on-board with text-mode OS for their servers, while at the same time, Linux distros are going the wrong way and forcing GUI installers, using a pointless graphical splash screen for the bootloader, and other nonsense that helps no-one, but scr

        • by chihowa ( 366380 )

          Because in 10 or 20 years UEFI will be like the old BIOS. It will do totally old stuff that nobody wants, and it will not allow new stuff, because of the same reasons of the that the old BIOS have.

          Of course that's true, but the E in UEFI is an attempt to make it last as long as possible. I'm not sure what's so objectionable about UEFI, though. It is, essentially, "a BIOS that addresses the decades of accumulated legacy bodging that is the PC."

  • ...what is the point of secure boot again? Do we still have problems with MBR viruses?

    • It's supposed to be a protection against bootloader-infecting rootkits. No-one questions that it can do this, but bootloader-infecting rootkits are incredibly rare things to encounter, and given Microsoft's long history of anticompetative business tactics it isn't hard to imagine their ulterior motive for pushing the technology.

  • Signing their key is the least Microsoft can do for using large parts of the FeeBSD TCP/IP stack in Windows.
    https://lwn.net/Articles/245805/ [lwn.net]

    • by gavron ( 1300111 ) on Monday July 01, 2013 @02:20AM (#44151551)

      MS has the LICENSE to use BSD code.

      They don't owe BSD anything.

      Next time you're thinking of whether to license YOUR code using GPL or using something
      that allows MS to use your stuff and give nothing back in return... remember this.

      Ehud

      • by dfghjk ( 711126 )

        You assume BSD is unhappy with this result. They are not...and the problem isn't MS using BSD's "stuff" and not giving anything back to BSD in return, it's not giving anything to YOU in return. BSD got precisely what they wanted in that transaction, you didn't.

    • Social conventions like owed favors do not exist in the world of business. When billions of dollars are at stake, there is no room to be 'nice.' That's why contracts were invented.

    • Windows doesn't use any of the FreeBSD TCP/IP stack anymore. It did at one time pre-Windows XP, but it was completely rewritten from the ground up prior to Windows XP, but many of the settings (registry settings) remained the same for compatibility.

      • Sorry, I just double checked, it was rewritten for Windows NT 3.5, and then carried over to Windows 95. So the FreeBSD stack hasn't been in use for nearly 10 years. Some of the ancillary utilities however, were never rewritten for some time and might have used some FreeBSD code in them. They carried the "Some parts... blah blah...Berkely... blah blah" messages in them.

  • Loophole (Score:5, Interesting)

    by Todd Knarr ( 15451 ) on Monday July 01, 2013 @01:47AM (#44151457) Homepage

    My bet would be that Microsoft refuses to sign the loader, saying that they can only sign if the loader's coded to only load binaries signed by a trusted authority (ie. Microsoft) and that allowing a loader that can load untrusted (ie. unsigned or not signed by Microsoft) binaries compromises the security of the boot process.

    • by AmiMoJo ( 196126 ) *

      It doesn't work that way. Canonical's shim is signed with Microsoft's key but will only load a Linux kernel signed by Canonical with full boot-time privileges. If the kernel is unsigned it doesn't get access to some UEFI features, they are disabled before starting it. This prevents people from writing "kernels" that are just rootkits which load the Windows 8 kernel up afterwards.

      So in fact Microsoft has already signed a shim that can load untrusted code, but on the condition that it does it in a safe way th

  • Can't they just use the already-signed blob?
    • Microsoft won't sign a blob that can simply load any kernal, because doing so would defeat the purpose of Secure Boot: An attacker could simply load the linux signed loader with their malicious rootkit and use that.

  • by ThorGod ( 456163 ) on Monday July 01, 2013 @02:21AM (#44151557) Journal

    I've tried both the newest PC-BSD and bsdinstall installers...and they leave a lot to be desired. :/

  • For what it's worth, Surface Pro (A Microsoft-built device) allows you to disable Secure Boot support if you so choose.

    UEFI -> Secure Boot -> Measured Boot (requires TPM)

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...