Mailinglist Archive: opensuse (924 mails)

< Previous Next >
Re: [opensuse] Re: UEFI
  • From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
  • Date: Wed, 24 Oct 2012 16:39:03 -0400
  • Message-id: <CAGpXXZ+hn3KxP07hFzhm11OJJmiiSpcCnSWk-=SQdVQkkziEbA@mail.gmail.com>
On Wed, Oct 24, 2012 at 11:27 AM, JtWdyP <jtwdyp@xxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It would appear that on Oct 23, Greg Freemyer did say:

On Tue, Oct 23, 2012 at 11:05 AM, Mark Hounschell
<markh-n2QNKt385d+sTnJN9+BGXg@xxxxxxxxxxxxxxxx> wrote:

Does this mean we won't be able to run any kernels other than opensuse
kernels?

Quick answer (that I expect most kernel hackers to use):

The spec calls for x86 PCs to have a bios option to disable UEFI Secure Boot.

With that disabled, you can do what you please.

I do hope that's what happens. But when I googled the secure boot topic about
a week ago I got the distinct impression that: while the spec allows for that
on x86 PCs, I read something that indicated the spec fell short of actually
requiring that the manufacturer actually include the means to do so...

It's a spec, not a gun. Lots of vendors partially implement specs, or
introduce their own extensions.

The supposed risk was that the manufacturer might be able to build it slightly
cheaper if they don't. And that some of them might not see the marketing
advantage of playing nice to multi-booters.

probably true, we will have to wait and see.

<snip>

So I got to ask, just how sure are you about that {disable secure boot} option
being implemented by ALL manufacturers???

Left my mind reading gear at home. And my crystal ball for reading the future.

<snip>

Long answer (which assumes Secure Boot is enabled):

This is linux. The SUSE team is doing its very best to make sure you
are still in control. Fortunately, they are also contributing their
solution to openSUSE.

Hopefully you know about private and public keys. Private keys are
used to sign, public keys to authenticate. (You will not have access
to the openSUSE private key, so you won't be able to sign kernels with
it.)

Yeah, Just barely well enough to use gpg to sign or encrypt something...
But how this relates to signing kernels is beyond my understanding.

The concept is a trusted vendor like microsoft will use their
private/secret key to sign their kernel. They will distribute their
public key to all the PC vendors to preload into a EFI Secure Boot key
table.

Then every time you boot, the UEFI Secure Boot module verifies you are
using a kernel signed with a authorized private key.

opensuse is developing an open/extensible solution that will leverage
their private key by installing their public key into a Secure Boot
key database.

If you have a true need to sign your own kernels, then I assume you
can get a copy of the extensible Secure Boot module that openSUSE is
developing and use it to install your own public key to the secure
boot key database. Then you will need to sign your kernels with your
private key.

I expect that a true kernel hacker would be up to that.

It's not really kernel hacking, but I see your point.

But what about those
of us who just like the choice of being able to choose to boot one of the
other small distro's now and then??

I will be extremely surprised if the next generation PCs can only boot
CDs/DVDs/thumb drives signed by Microsoft.

So whatever the process is to boot a non-Microsoft external media is,
you'll have to use it.


I'm not ready for a new PC yet anyway. But
when I am, I would greatly appreciate it if OpenSuSE's solution would allow me
to use OpenSuSE's grub menu to also boot other Linux. including those that
haven't the resources to have their own secure boot solution. {Without
requiring that I have hacker grade skill levels.}

I don't think that is currently envisioned, but you need to ask about
that on the blog comment area. The blog links were posted by someone
else early in this thread. (I am not developing / maintaining the
SUSE solution, I'm just telling you what they are doing.)

Speaking of other Linux though: Even assuming that I only wanted to multi-boot
major distro's that have secure boot strategies in place, will it be possible
to have one secure boot loader chainload another with a different secure boot
strategy?? (I heard that Ubuntu {for example} isn't even going to use grub2 on
UEFI systems due to anticipated legal problems with the GPLv3 license)

The SUSE Secure Boot extension module is itself extensible. It
creates a small database to securely hold private keys. There is in
turn a mechanism provided to update that private key database. Red
Hat has already said they like the sounds of that and will likely use
the same solution. (After all the SUSE module code is opensource (I
assume) so they can add it to their own boot CDs etc..)

Hopefully some (or many) of the other Linux Distros will also support
the SUSE extension and thus they can all be compatible with a single
system.

My preference has for a long time been to keep one manually updated version of
grub on a separate grub partition installed to the MBR, And to let each one of
several installed Linux install their own automatically managed boot loaders
to their own "root" partitions. That way I can easily use my own pet names for
the menu choices of the entries I manually update {such as "kid's Linux" for
the one with *_only_* rated G wallpapers installed} AND also have generic
chainloader entries to use whenever I didn't find the time to update it after
a kernel change... I was hoping that I could simply let OpenSuSE install it's
bootloader to whatever passes for the MBR on an UEFI system. And them learn
how to use the stuff in /etc/grub.d to get customized menuentry to be listed
before the automatically generated ones... But I doubt it will be that easy.

Seriously beyond my knowledge at this point.

The actual developers working on the SUSE solution MAY know the answer
by now or they may not.

There is very little actual hardware to play with at this point.

Greg
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups