Announcement

Collapse
No announcement yet.

The UEFI SecureBoot Saga For Linux Continues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kano
    replied
    No i wont because if somebody does not find the option to disable secure boot he is most likely not able to use linux as well...

    Leave a comment:


  • steveriley
    replied
    Originally posted by linux5850 View Post
    I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.
    In the comments section, someone asked about TPM, and the response was that SecureBoot is designed not to require one.

    Leave a comment:


  • Kano
    replied
    @Q

    Kanotix is definitely not dead, maybe look at our homepage, we just release a Hellfire (squeeze) update and a Dragonfire (wheezy) preview.

    But if EVERYBODY can get a signed bootloader then this system is absolutely pointless. For x86 you just have to find a setup option to disable secure boot - usually secure boot can only work in uefi mode anyway. So when you would force a boot via csm (and bios emulation) how should secure boot be active if thats done via quick boot selection?

    If you see secure boot as something positive to your own security that means that could be sure that nobody managed to put in a spy module to save your encryption keys if you encrypt your data like it is possible when you hijack the mbr for this and then execute maybe truecrpt later but store the key.

    I don't understand why ms would give away a signed 3rd party efi loader, you can be 100% sure that it will be used for exploits. If you dont need security features you can disable em on your own. It would be interesting to know if there is a uefi spec to update the included public keys. Basically it should not be that hard to do when you have got access to the uefi, you can extract, change (there are several tools to modifiy uefi, just for another purpose currently) and flash your own keys.

    Even if the key area would be write protected after first write you could still replace the eeprom chip, which is a piece of cake on a desktop system, well could be tricky on a laptop. When YOU are able to control it, then you can gain a little bit more security, if you cant it would be just like without.

    Leave a comment:


  • disi
    replied
    Easy enough: avoid any hardware with a Windows 8 sticker?
    This is what I am going to do...

    Little example, me buying a netbook:
    1. tell the vendor to rip out the hard drive and put a SSD in
    2. do not bother to install Windows on it and keep the licence
    3. after some research, the third vendor was OK with that

    Leave a comment:


  • allquixotic
    replied
    Originally posted by Qaridarium
    in your world professionals only use UEFI ? i think REAL Professionals use coreboot in the bios flash rom and a hardware jumper to set the boot rom to read only

    LOL !!! tell me how do a hacker BEAT this security solution ?
    That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

    It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.

    This is what secure boot does, but instead of network data, it verifies executable code on disk.

    My personal commitment to fight secure boot's unnecessary restrictions on regular users is this: I will never purchase a consumer device (PC, laptop, tablet, smartphone, etc) that has Secure Boot enabled, and cannot be disabled. Those devices can sit on the shelves in the stores, and I will buy devices that let me customize the operating system how I want to.

    However, if someone expresses interest in using secure boot in an enterprise context (a server, I mean), I will probably let them know that it can be a good thing, if you know what you're doing. But it does add a lot of unnecessary headache to the configuration/installation of the operating system and software, so we'd have to perform a feasibility investigation to make sure that there are no roadblocks.
    Last edited by allquixotic; 01 June 2012, 12:52 AM.

    Leave a comment:


  • linux5850
    replied
    Originally posted by agd5f View Post
    secureboot is coming whether you like it or not. You may be able to disable secureboot in the bios, but every bios vendor will implement it differently and some may forget to implement it at all. How do you tell a new Linux user that they have to hit F11 or maybe Delete or maybe F2 during the first few seconds of boot and then wade through a bunch of bios menus to disable a feature called _secure_ boot (let that sink in) just so they can try out this new Linux thing. Kind of a high bar. Realistically you need to support secureboot if you want your OS to be accessible to a wide audience.
    I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.

    Leave a comment:


  • allquixotic
    replied
    Originally posted by Qaridarium
    will it be possible to just flash a coreboot with flashrom over the BAD and EVIL UEFI ?
    Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).

    Leave a comment:


  • linux5850
    replied
    Barring firmware backdoors

    Barring firmware backdoors
    I think that's the real purpose of secure boot and UEFI. Not that there isn't a legitimate case for secure booting but if it prvents you from examining ALL the source code and the firmware then you don't really know who has ultimate control of your pc and data.

    Leave a comment:


  • allquixotic
    replied
    Originally posted by johnc View Post
    We're finally getting Steam and now you want to kill off the high-performance video drivers?
    It's not whether anyone wants to or not. It's as Alex said: for systems where disabling secure boot is not an option (because disabling it isn't implemented properly or not at all or the user is too stupid to disable it), it will be impossible to get a signed bootloader / signed kernel for a system with the proprietary modules. That's because the proprietary modules essentially do "user-space modesetting", and most of the real low-level logic is done through a user-space library. Allowing this kind of low-level access into the hardware from userspace would not be permitted by the secure boot folks; they wouldn't allow you to sign a bootloader and kernel that has this kind of gaping security hole, where anyone with root could just write to an arbitrary area in memory.

    As a professional security guy in my day job, I have to say that it's not a terrible idea to create a system where only signed binaries can run. This is almost too inflexible to be usable on the desktop, but on the server you can sign everything during development/integration, so that your production environment has 100% signed and pre-arranged software with no chance for a virus to even execute.

    This would be called a "defense in depth" strategy: our hope is that a web server (or any type of server) would be able to stop attackers at the front door, by preventing the web server itself from being compromised. Or even if it were compromised, ASLR would prevent them from finding the address of a library and writing shell code; they'd just crash the server with a segfault on their first pointer dereference or memory read.

    But the reality is that really crafty, malicious hackers doing naughty things can bypass a lot of our front line defenses. So the hope is that a fully trusted, signed system would prevent execution of arbitrary code. I'm not sure how interpreters would work in this environment, though; anyone who could execute `python' (or inject commands into python using a web form or something) would have quite a lot of power on most systems.

    Basically, from the point of view of a paranoid server security guy trying to deploy a production server, trusted boot makes a certain kind of sense. But I certainly wouldn't want it on my home computer.

    Everyone please remember -- this is very important -- that Microsoft is not requiring that x86 mobo/CPU manufacturers lock down their hardware with secure boot. It should be possible to disable secure boot with a simple BIOS switch on x86 hardware. So as long as you aren't running an ARM device built for Windows 8, secure boot won't be a problem for you if you can follow some simple instructions. It's nothing like rooting an Android phone; it's literally just an Enabled/Disabled switch in the BIOS, that's all.

    For those who want to run Linux on an upcoming ARM device with enforced Secure Boot, we're basically going to have to break the encryption or find a security vulnerability that allows us to "root" the device. But we have plenty of experience with that from Android and iOS, so I'm sure the community will find ways to do it. This Phoronix post and Matthew's article have absolutely nothing to do with the ARM case, though; that is a whole separate subject.

    From the perspective of the x86 market, though, Secure Boot is just another option... it doesn't force you to do anything, it just gives you the ability to do something that may increase the security of your box. And for people who are safeguarding millions or billions of dollars worth of data on a box, that is a material difference to them, and they want it. If you don't, you can still buy that hardware, and disable the option.

    The ideal situation would be that the option is enabled by default on products where a majority of users want it, and disabled by default (or not even present) on products where a majority of users don't want it.

    So that would lead to a situation like this :

    Servers (especially for enterprise use): Users want it; enabled by default; compatible with Linux thanks to signed trusted system (though not custom/proprietary drivers)
    x86 Desktops and x86 full-fat laptops: Users don't want it; disabled by default; compatible with Linux because it continues to work as it has with previous-gen hardware
    ARM phones and tablets: Many users don't want it but carriers require it because they're assholes; enabled by default; compatible with Linux thanks to signed trusted system (though not custom/proprietary drivers)
    ARM Desktops: Do they exist? If they do, I'd hope it'd be disabled by default... but if you ask Microsoft, it'd be enabled just by virtue of the architecture.

    Reality is very close to the above, and the main point of contention here is actually with ARM devices that have a cellular baseband and are connected on a cellular network such as 3G or 4G. The main objection(s) that carriers have to allowing uncontrolled code to run on the devices is:

    1. Regulatory compliance: they need to retain strict control of what the baseband is doing to keep from violating laws by e.g. the FCC
    2. Usage restriction/management: They don't want to let you tether, or if they do, they want to limit you to 5GB tethering plan at an additional fee
    3. Bloatware: makes them money if you can't remove apps; developers pay the carrier extra $$$ to have apps installed that you can't remove. You could remove them with full trust e.g. with secure boot disabled.

    Bottom line: if you expect to run Linux on a Windows 8 ARM tablet or ARM ultrabook, you're probably going to be disappointed. You MAY be able to get it working with the help of Matthew Garrett's efforts towards Secure Boot with Fedora or RHEL, but it may cost you money and you will definitely be limited as to your choice of software and drivers. If you aren't looking to run Linux on such a device, you can probably disregard this entire discussion.

    For me, I will buy x86 desktop and laptop hardware with secure boot, but I will heavily research the product before buying to make sure that the feature is present and functioning properly, to disable it from the BIOS. Because as Alex said, it's possible (though unlikely IMHO) that the BIOS vendor could screw it up and cause the feature to be stuck in the "enabled" position, which would make your device as heavily locked-down as an ARM device.
    Last edited by allquixotic; 01 June 2012, 12:37 AM.

    Leave a comment:


  • johnc
    replied
    Originally posted by Qaridarium
    maybe the UEFI crap will kill the closed source drivers from AMD and nvidia?

    i hope the kernel Developers stay hard at this point then the big lose with the name UEFI is a little win for opensource,
    We're finally getting Steam and now you want to kill off the high-performance video drivers?

    Leave a comment:

Working...
X