On 06/02/2012 01:26 AM, Sam Varshavchik wrote:
[snip]
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.
Well, *obviously*, nobody expects secure boot to do anything magical
here. If you want to use these features without restriction, secure
boot is useless as you said, so don't use it.
Some people will still want to use secure boot because they find it
useful - you might not, but there are a lot of people out there. For
these people, you have two options: (1) block these features and/or (2)
set them up so you can define exactly what they will be used for in your
policy (if possible). In other words, the kernel should make sure that
it won't load anything it can't trust (especially things it can't trust
not to load another kernel) while still providing as much features as
possible.
This is the classic convenience vs security trade-off, and I don't think
anyone is disillusioned about that "revelation". I say again, if it's
too inconvenient to have to configure/cripple/block these features, then
you can't possibly use secure boot in a useful manner, and hence
shouldn't even bother with it. (Well, I know you know.)
No vulnerability is needed.
Which is why you will never have a trusted boot of an open Linux kernel.
I can't talk about the feasibility of securing the entire kernel, but I
kind of got the feeling that Alan Cox knew more about it, maybe he can
comment a bit on that (again). I know a lot of smart people are
thinking about it very seriously, so we shouldn't say it's impossible
just yet.
I guess the main problem comes from virt done entirely in userspace, and
I admit I have no clue what the plan is to address these. I would hope
some reasonable techniques exist for this already, or Microsoft wouldn't
have invested so much in secure boot (they'd have the same issue
afterall). Some basic userspace initialization integrity checking would
already go a long way I think.
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.
If we're still talking about the process to add your own keys (that's
what I was talking about anyway), know that it's confirmed by Microsoft
for x86[0]. Now all vendors who don't comply [don't provide the
interface to do it] won't be certified by MS. They don't want that.
Why Microsoft would help here is certainly a bit of a mystery at first,
but as I mentioned already, they certainly fear a PR and legal
nightmare, because even if they don't explicitly require anything many
vendors might not care to add the feature. And then they'll most
certainly happily hide behind Big Bad Microsoft, because
"Windows-certified hardware won't boot alternative OSes on x86" (that
already made the news even though it's wrong). They would be quite
right too, being an OEM kind of frees you from having to deal with
end-users; the problems with their products are delegated to the buyer,
here, Microsoft. So yes, it all makes sense in the end for MS to demand
that of their vendors.
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?
Well the math doesn't compute here, it's cryptographically impossible.
I mean you could sign a shim that won't verify the integrity of the boot
loader, but you would gain absolutely nothing from secure boot then, it
makes as much as disabling it entirely.
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 don't think we understand each other, I was joking. It makes little
sense for the OS to check the integrity of the firmware if the firmware
itself is the one thing that verifies the integrity of the OS (via the
loader). I mean it's not even a real catch-22, you won't ever boot the
kernel before the firmware, so this is a non-issue. Anybody can sign
all the firmwares in the world all day long, nobody's gonna care nor
look at these signatures.
'Real sorry if I missed an obvious use-case here, but in any case it
wouldn't part of secure boot I don't think.
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.
Why would they sell their OEM arrangements (in the form of loaders
signed with their own key) explicitly for people to load their own
software if it's to sue them the day after? I know they have a
reputation to do crazy things, but it doesn't take a genius to see the
problem in that business model.
Now if the loader they signed really allows for an open boot as in
"executes anything without checking for integrity of the next component
up until the point the user has complete control over what to execute
next", well, see above, it's simply a stupid idea to begin with and they
should blacklist it.
PS (OT): I'm pretty confident we fell in there[1]. All in good fun
though ;). At least I hope so, else I apologize. It's how it's done on
the Internet.
[0]
http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf
[1] https://xkcd.com/386/
--
t
--
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
