Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: Defeating Secure Boot With Linux Kexec

  1. #21
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

    Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.

  2. #22
    Join Date
    Dec 2012
    Posts
    97

    Default

    Quote Originally Posted by mrugiero View Post
    Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

    Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.
    Android can run on some x86 devices with SecureBoot last I heard, but the market for x86 devices is small, let alone ones with SecureBoot...

    With ARM platforms, it uses the ARM TrustZone, which can basically serve the same purpose and more that SecureBoot does.

  3. #23
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,333

    Default

    Quote Originally Posted by MWisBest View Post
    Can you by chance provide some references for this? I'd be very interested in it!

    If this sounds like sarcasm or trolling, it isn't, I'm geniunely interested in reading about this... I just know it can be hard to tell on the internet about things like this sometimes, especially in places where trolling can be common like here.
    Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.

  4. #24
    Join Date
    Dec 2012
    Posts
    97

    Default

    Quote Originally Posted by curaga View Post
    Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.
    Thank you very much, I'll have a look at it!

  5. #25
    Join Date
    Aug 2007
    Posts
    6,675

    Default

    I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work. I don't consider the ReatOS loader as valid windows loader example.

  6. #26
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    466

    Default

    Quote Originally Posted by erendorn View Post
    Protection from rootkits and malware control at the hardware interface layer?
    Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.

  7. #27
    Join Date
    Apr 2011
    Posts
    114

    Default

    Quote Originally Posted by Kano View Post
    I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work
    You start the Windows kernel with kexec in exactly the same way that you start the Linux kernel with kexec - load it, generate the appropriate handoff data and jump to the entry point. kexec-tools has implementations for the kernel and multiboot files already, it wouldn't be that much work to implement Windows support.

    I don't consider the ReatOS loader as valid windows loader example.
    You don't consider something that can load and execute the Windows kernel as a valid example of something that can load and execute the Windows kernel? Interesting position.

  8. #28
    Join Date
    Sep 2012
    Posts
    792

    Default

    Quote Originally Posted by movieman View Post
    Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.
    but then, locking you out doesn't require secureboot on ARM, and it's specifically non compliant for secureboot on x86. So you couldn't care less compared to "nothing", leaving you in an odd position to complain either way.

  9. #29
    Join Date
    May 2013
    Posts
    43

    Default

    Quote Originally Posted by Pajn View Post
    No that is totally against the GPL license.
    You can't mix GPL and proprietary code.
    But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.

    https://git.kernel.org/cgit/linux/ke...s/tags/v3.12.3

  10. #30
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,572

    Default

    Quote Originally Posted by IsacDaavid View Post
    But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.
    I think that's why the firmware files don't actually get built into the Linux kernel, but instead are treated as data files.

Posting Permissions

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