News for hackers. Stuff that matters.
Re:Uncorrectable freedom and security issues on x86 platform... by saurik on Friday March 03, 2017 @09:38PM (#13788833)
> Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL.

Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.

Re:Uncorrectable freedom and security issues on x86 platform... by cyphar on Friday March 03, 2017 @10:16PM (#13788982)
> > Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL.

> Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.

It's not entirely accurate. Effectively what most modern distributions do is that they have a "shim" which is signed by Microsoft. That shim then enrols the distribution's own UEFI keys on the laptop. So their kernel is signed with both their own key and Microsoft's key. This means that you can modify your code without "permission" from Microsoft. openSUSE, Fedora and Debian all employ this tactic so that our distributions can boot on newer laptops.

Do I wish this wasn't necessary and that everything ran core boot? Yes. Is there a better way of handling this problem? Not as far as I know.

Re:Uncorrectable freedom and security issues on x86 platform... by int_19h on Friday March 03, 2017 @10:36PM (#13789066)
I don't think GPLv3 anti-DRM clauses would kick in here. They would if 1) someone was distributing a combination of a Secure Boot-only machine with your software installed on it, and 2) the loader (which is the only thing really validated by Secure Boot) would actually try to continue the chain of trust, and validate all the other bits, such that the user cannot run a modified version of your software.

I'm pretty sure that neither of those is the case, however. Once the system boots using the signed loader, it's really just Linux, and you're free to replace the kernel and any bit of userspace as usual.

Furthermore, I seriously doubt that anyone is selling machines with Linux preinstalled that have Secure Boot which cannot be turned off - simply because that would become known pretty fast, and even aside from licensing issues, would elicit a very hostile reaction from the community (and hence many potential buyers).

Re:Uncorrectable freedom and security issues on x86 platform... by doubleunplussed on Friday March 03, 2017 @11:05PM (#13789179)
I'm not 100% sure that this is what's being referred to, but in Ubuntu for example, the initial bootloader is a program called "shim". Microsoft signed shim - so computers with secureboot will run it.

Shim contains keys from Canonical or someone (I'm not sure), and verifies that GRUB has been signed by Canonical before running it. Then when GRUB runs the kernel, it calls back into shim first to verify the kernel has also been signed (Actually that last step wasn't enabled yet last time I checked).

So basically, until Microsoft changes their keys, by signing shim they've given Canonical permission to sign things. But unless you disable secureboot, you can't run a custom kernel unless you convince Canonical or Microsoft to sign it.