Thibault Nélis writes:
On 06/01/2012 02:33 PM, Sam Varshavchik wrote:If the shim enables anyone to execute any code they wish, "on bare metal", it makes the entire concept of trusted boot completely and totally moot.Not anyone, just Fedora. If Fedora starts to fuck up and many Windows users report being infected, and it turns out that hackers are using vulnerable Fedora kernels to host malware and chainload to Windows, then they will blacklist the shim. Since Fedora doesn't want that, the kernel maintainers, the boot loader maintainers, and the shim maintainers will make sure that nothing is vulnerable on their end, and keep the key secure.
I don't think the whole picture is fully understood. There does not have to be any vulnerability, for a common definition of "vulnerability", for this to occur.
Right now, there is a documented set of kernel features, in every stock Linux kernel, that can be used to instruct the kernel to cease all activity, and execute arbitrary code; boot another OS, if you want. I'm being deliberately vague.
But they've been in Linux for ages. They are documented, just not widely known. This is not a "vulnerability". This feature is used by pretty much every enterprise Linux seat. On one memorable occasion, circa 4-5 years ago, my "enterprise" job at that time had to deal with a pesky RHEL kernel bug. With some assistance from RHEL engineering, the particular feature in question was used it to gather diagnostics, isolate, and track down where the kernel bug is. It's not actually being used to boot another OS, but to implement different functions that are often needed in enterprise environments.
And I used it myself, on occasion, for the same reasons. I think I still have it turned on, on one of my headless servers, currently on F16, soon to be on F17.
If such a mystery beast, as a signed Fedora kernel, emerges; where "kernel" refers to the standard Linux kernel, no more modified than it is already modified in Fedora, right now, then malware can simply take the signed Fedora kernel. Boot it. Then tell the kernel to invoke this specific feature, in order to execute the virus code.
This is what being an open OS is all about, folks. The OS does not prohibit you from accessing the underlying hardware. You are free to halt the OS, and execute your own code, at any time.
I repeat: this is NOT going to happen. If you allow an open operating system to boot, as a trusted boot, then "trusted boot" ceases all meaning whatsoever for a non-free OS that requires a signed chain from the hardware. And I won't even start on the subject of virtualization, like KVM/Qemu/libvirt.
No vulnerability is needed. Which is why you will never have a trusted boot of an open Linux kernel.Really, I feel no point in discussing this if something this fundamental cannot be comprehended or understood. I simply can't find a better way to explain this.
Now, if Microsoft wasn't around, then, yes, you could possibly have something like this trusted boot come about.
But not when the same hardware needs to run a non-free OS.As I mentioned elsewhere, the only end game I see here, is hardware that either supports non-free OSes, or free OSes. But not both. If you want a trusted boot environment, you cannot support both free and non-free OSes on the same hardware.
This is fundamental. Nothing, no $100 cockamamie certification process, no PR bullshit spin, could possibly change this fundamental property, in any shape, way, matter, or form. Either accept this concept, or don't, but I don't think I can explain it any more clearer.
And, if there's a process by which my own signing key acquires the magical pixie dust, that does not involve, in any way whatsoever, any outside party giving their stamp of approval, that blows the entire boot loader trust chain wide open.Yes there is a process, indeed it doesn't require any third-party, and no it doesn't blow anything up.
No, there is no such process in existence right now. You just think that there will be, in the future.
Not going to happen. No. Never.
This is the pie in the sky. This part, is not going to happen. Microsoft will make sure of that.Another bet? As Alan Cox said, the public outrage if it doesn't happen will be immense,
Maybe somewhere in the EU, perhaps. I do not believe that it will be enough.
Nothing is lost yet, and awareness is raising even before the release of the technology. I know the fight isn't won yet either, but if everyone does its part we won't even have to lift a fist, and judging by what Microsoft is doing offering $100 signatures via Verisign (which isn't very expansive for
Tell you what.Let's revisit this, when there's a key that will boot any Linux kernel, that anyone can build themselves, and install, ok?
I'm going to throw in another 1,000 quatloos on a different bet. Microsoft will also require OEM's boot firmware to be signed by Microsoft's key, in order for a Microsoft OS to boot off it. Otherwise, the user will be greeted with a nicely-rendered message that their hardware is incompatible.You're going meta. Who's gonna check the integrity of the firmware? Can you
I tell you who: Microsoft. And their OS, when it boots. The only way to work around it, would be copyright infringement.
I have a dim recollection of a case from a few years ago that has some relevance. I remember pretty much nothing of it, but I recall it was some kind of a smart-card related situation, where some hardware checked a few bytes on the smart card, that carried the manufacturer's name on it. A competitor made their own cards, and put the same bytes on their smart- cards, so that it works with the hardware in question. They were sued, for copyright infringement; the judge ruled against them. It might not've been smart-cards, it might've been one of the portable gaming platforms.
Anyway, that won't stop, of course, an OEM &/| Microsoft from suing anyone that produces hardware containing an image signed by a Microsoft key, but actually executes something else, that allows for an open boot.
Attachment:
pgpq6UTGVUkzB.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
