UEFI Secure Boot Still A Big Problem For Linux

[Ansla]

What about the initrd, is it secured by tpm?

The initrd itself is not a concern, it's just a minimal root filesystem after all, the kernel modules included in it that are not signed will be ignored and that's it.

[alain]

Secure Boot isn't just a way for Microsoft to fight against mofified pirate copies of windows which can be found around the world, rather than malwares ? With a colateral damage : linux and other "small" os...

It would be something similar to the way DRM is due to act against illegal copies of movies, music and so on...

Alain

[Kano]

@Ansla

So you think the part that asks for the password if you use cryptsetup can not be modified in a way that it could get access to root filesystem after pw entry and could send the pw over internet later?

[Ansla]

And /bin/login on the root partition can be modified as well to send passwords over the internet, but "secure boot" doesn't care about userspace, just the kernel. If they start enforcing signed binaries for userspace as well this goes well beyond "no more nvidia blob", you won't be able to run anything compiled locally on the "secure" OS.

P.S. this will probably come as "secure boot 2.0"

[Kano]

Well when you think of secure then it is somehow unlogical when you would not combine it with encryption. The funny thing would be: even when secure boot would only allow ms bootloaders then you could most likely still boot the the install media. But that has got a konsole and via that you have got full access, no pw needed.

[DeepDayze]

From article: "Signed Linux kernels must refuse to load any unsigned kernel modules."

Why? Secure Boot requires a signed kernel (or isn't it, rather, a signed boot loader?) but the kernel can do anything after boot. Yes, it defies the idea that you should only run trusted code but that can be a boot option or, as someone wrote above, the out of tree projects can provide signed modules.

After kernel loads there should be *nothing* done to modify any of the *trusted* components otherwise the chain of trust is broken...that's where Secure Boot will bite. The trusted components need to be walled off

[Eragon]

I can see the problem for ARM based devices. But for anything x86 / x86-64 ... didn't the recently published documents by microsoft specify that every windows 8 computer MUST have an option to disable secure boot? So then, what's the problem? offcourse, you would have to turn of this security feature to be able to run linux, but that is unavoidable I think given the way the development model works with everyone building his/her own distro, kernel, etc.

[Ex-Cyber]

I can see the problem for ARM based devices. But for anything x86 / x86-64 ... didn't the recently published documents by microsoft specify that every windows 8 computer MUST have an option to disable secure boot? So then, what's the problem? offcourse, you would have to turn of this security feature to be able to run linux, but that is unavoidable I think given the way the development model works with everyone building his/her own distro, kernel, etc.

It's not unavoidable at all. Even in the worst case, a user/admin should have the option of signing his own bootloader/kernel/initrd.

[droidhacker]

And in the end some people do not understand why they should open the chassis and lose warranty just because Linux is to bad to run out of the box.

I don't know what the German law is regarding this, but in North America, it is ILLEGAL for a hardware vendor to blanket void warranties for something like opening the box. The hardware vendor is required to show that the user actually CAUSED the problem for which it is being serviced.

[droidhacker]

If your kernel loads unsigned kernel modules then it also permits you to backdoor Windows, which means that Microsoft would blacklist it.

I don't see how it matters if MS blacklists anything.... its the bios that you have to worry about.