Find the answer to your Linux question:
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 23
The thing that makes me nervous about UEFI is that there is already proof of concept work being done that if it pans out and makes it in to the ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    401

    The thing that makes me nervous about UEFI is that there is already proof of concept work being done that if it pans out and makes it in to the wild will allow direct exploitation of secure boot and the preloader through the network stack. It's still full of bugs. But everybody from top knotch white hats to the russian mafia is working on it. If somebody makes it practical that could potentially create the first true crossplatform malware and would make it next to impossible to find or remove the crap.

  2. #12
    Linux Newbie SL6-A1000's Avatar
    Join Date
    May 2011
    Location
    Australia
    Posts
    120
    Quote Originally Posted by mizzle View Post
    SL6, to answer you question about why sign the pre-loader and not the whole kernel/boot stack, read this page:
    [Phoronix] The UEFI SecureBoot Saga For Linux Continues


    So, there are two schools of thought here: Enable Linux to boot in a mixed environment or enable linux to use the new software secure boot in the same way Microsoft does.
    All this is, is Microsoft basically saying in short "bend over while we screw you!" Secure boot is overrated...!

    While i don't like the fact that the Linux Foundation is choosing to go along with these shenaningans, that do have Linux and others at heart.

    With that out of the way, I can see the issue with introducing it as a part of GRUB, but that still leaves doubt. What i mean is GRUB can load arbitrary code during runtime, so wouldn't a solution to this problem to make it so that when a person makes a change to the grub bootloader, the changes don't occur after reboot. Basically the update-grub command isn't run by the user but instead run as apart of the shutdown process along with re-asigning the secure key.

    This would allow for users to still edit the bootloader as they feel fit but it just means they can't update it as they feel fit.

  3. #13
    oz
    oz is offline
    forum.guy
    Join Date
    May 2004
    Location
    arch linux
    Posts
    18,733
    Don't know but do believe UEFI Secure Boot could become a huge issue for lots of Linux users. We are beginning to see more help request threads on it in this forum already, and nobody new to an OS wants to be saddled with such a road block right from the get-go. Maybe after hundreds of thousands of computers/components are returned to the hardware makers as defective they will decide to put a proper fix in place.
    oz

  4. #14
    Just Joined!
    Join Date
    Dec 2010
    Posts
    21
    But Oz, Secure Boot IS the fix. People confuse the issues. UEFI is buggy but Secure Boot is just one of it's many features that happens to be enabled by request on machines that come pre loaded with Windows. If you choose to buy a machine with Windows 8 it's your own fault when things wont work right when trying to dual boot Linux. You can't return a perfectly working Windows machine because of that.
    If UEFI didn't have Secure Boot, we wouldn't be here talking about this issue, other than the fact a few systems will still suffer from badly implimened UEFI, it would not cause the huge problems we are having because of Secure Boot.

    Secure Boot is supposed to ensure no malware gets into the system before it gets to you.. I'd like to see the stats on this huge problem of OEM's having their systems taken over by malware before they are sold that would cause such a problem that would require such draconian measures as Secure Boot. That doesn't happen except in 3rd world countries that use hardware clones and pirated software. It's BS and Microsoft knows it.

    The OEMs get paid by Microsoft to sell Windows 8. Microsoft pays the OEMs for a portion of the hardware cost so they can make these machines cheap to consumers. The OEMs are all too happy to tow Microsofts company line and not give help for UEFI & Secure Boot - they don't want to make it easy on people to get around Microsofts strong arm. This would upset Microsoft the OEMs cash cow. If any OEM is a Microsoft partner, or a certified reseller of Windows, you will not get any help from them for those machines.

    I think The Linux Foundation is doing the right thing here. The alternative is a shim like Fedora and Ubuntu use but many distro devs don't want to mess with that. Many distros don't even have any UEFI support at all let alone having to fight getting around Secure Boot. At least this is a solution that can or should be able to work with all distros and or other boot time tools with minimal fuss. Fedora's shim uses a Microsoft signed key ( actually they have a non signed version also https://fedoraproject.org/wiki/Secureboot) and Ubuntu's version isn't signed but the package is signed while the shim inside is not.. if thats not confusing enough LOL. Secure Boot implementation of Ubuntu 12.10 (Quantal Quetzal) | falstaff – yet another tech blog Because the binaries are Microsoft signed, there can be no source code given to the public. Talk about just Screw Open Source big time.. this brings up tons of other issues like when licensing Linux distros. The Free Software Foundation which sees things more black and white must really be throwing a fit. I'd like to see Stallman and company get around to finishing Hurd ( their kernel they have been working on for 20 years), it might be nice to see which direction they will go as the hackers they are, to help stop this madness. Hurd I understand is still being developed and may be a Linux kernel alternative in a few more years.

  5. #15
    oz
    oz is offline
    forum.guy
    Join Date
    May 2004
    Location
    arch linux
    Posts
    18,733
    Right, but while I don't fully understand all the details involved, what I'm saying is that I don't think the Linux Foundation, any Linux distribution, its developers, or its end users should ever have to answer to Microsoft (so to speak) in order to use Linux on their own computer hardware. It all seems like quite a mess to me, and I don't have any answers, but it will surely work itself out one way or the other in the end.
    oz

  6. #16
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    889
    At some point, I see this all coming to a head in court. Red Hat and SUSE also sell desktop x86 software, and if MS and OEMs aren't playing ball that opens the door for an antitrust lawsuit.

  7. #17
    oz
    oz is offline
    forum.guy
    Join Date
    May 2004
    Location
    arch linux
    Posts
    18,733
    Quote Originally Posted by mizzle View Post
    At some point, I see this all coming to a head in court. Red Hat and SUSE also sell desktop x86 software, and if MS and OEMs aren't playing ball that opens the door for an antitrust lawsuit.
    That would be my guess as well.
    oz

  8. #18
    Linux Guru Jonathan183's Avatar
    Join Date
    Oct 2007
    Posts
    3,043
    A better solution would be a user acceptance of a binary directly based for example on md5sum values.
    There should be no requirement for an M$ issued key. People can use an M$ issued key as a shortcut to accept binaries if they wish to ... but I want the option to check this myself and reject the accept everything which has been signed by a particular key or org.

    Actually have the option at boot time to review and reject/accept keys including those previously accepted (based on md5sum/sha1/a.n.other method etc) ... this would actually give control of the system to the user/owner. It would also allow user recovery of a system even if a key was compromised.

  9. #19
    Linux Engineer
    Join Date
    Mar 2005
    Location
    Where my hat is
    Posts
    766
    Folks need to realize that it isn't Microsoft that's driving the UEFI standards. If you look closely at uefi.org, Microsoft is but one voice in the rush to make this a standard. The standards workgroup is chaired by Intel, not Microsoft. And if you look at the Board of Directors, the chairman is Mark Doran from Intel.

    Far too many are willing to jump on the "bash Microsoft" wagon again, when it's not just Microsoft driving the initiative. There are 11 major companies involved in this.
    Registered Linux user #384279
    Vector Linux SOHO 7

  10. #20
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    889
    Quote Originally Posted by retired1af View Post
    Folks need to realize that it isn't Microsoft that's driving the UEFI standards. If you look closely at uefi.org, Microsoft is but one voice in the rush to make this a standard. The standards workgroup is chaired by Intel, not Microsoft. And if you look at the Board of Directors, the chairman is Mark Doran from Intel.

    Far too many are willing to jump on the "bash Microsoft" wagon again, when it's not just Microsoft driving the initiative. There are 11 major companies involved in this.
    Based on some other threads in which people are having problems (or maybe it's this thread), the standards aren't the problem. It's the lack of the implementing the actual standards such as requiring UEFI to allow disabling of secure boot (allegedly, I haven't messed with any new systems).

Page 2 of 3 FirstFirst 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •