Mailinglist Archive: opensuse-project (271 mails)

< Previous Next >
Re: [opensuse-project] UEFI situation
2012/6/26 M. Edward (Ed) Borasky <znmeb@xxxxxxxxx>:
On Mon, Jun 25, 2012 at 9:01 PM, Michael Chang <mchang@xxxxxxxx> wrote:

As one of the guys AJ mentioned who is working on the issue, I could
tell that two basic principles for openSUSE


[snip]

2. Be equal or friendly with other distribution
That means the solution has to align with what most other distribution
be able to choose and would allow co-operate with them. This implies
the windows signing service would be used as it's an fair offer for
all with a universal key installed. Until there's another signing
authority recommended by uefi forum, this is the only possible way to
go.

The Fedora proposal, presumably blessed by Red Hat, seems radically
different from the Ubuntu proposal, presumably blessed by Canonical.
So is there a "middle ground" between the two that would be friendly
to both?

By reading ubuntu's plan for download version I believe it's similar
with fedora's, except these difference:

1. Kenerl and kernel module signing is not required
2. They choose efilinx (bsd licensed) as default boot loader as gplv2
licensed would have potential law infringement if not publish private
key and it's certificate would be revoked by MS

For preload or Ubuntu certificated machines it would require firmware
to enroll their KEKS, but this should not compared with Fedora as it's
vertically integrated product with OEM selling for profit and not the
case for openSUSE as well.

So I think for open & free download distributions, use microsoft
signed first stage tiny bootloader to load self signed distribution's
bootloader could be a consent.



[snip]


I'm a big fan of simplicity - as in "do the simplest thing that will
work". There are an awful lot of "moving parts" here. There's the
firmware, the boot-sector-resident code, the rest of the bootloader,
the initrd and the kernel just to get to the point where all the other
miscellaneous code running as a privileged user gets into RAM. After
*that* is all accomplished, *then* all the userspace stuff can happen.

To me the most simplicity is do nothing, yeah this could be an option
if you ask me for it. Ask user who want to run free distribution to
disable secure boot is not entirely a bad idea, if you agree they
should suffer from the decision made by the monopoly company and go
protest it. :/

I think what the distribution is thinking and doing is a way to
circumvent the situation, it's not an regular procedure who really
wants secure boot technology but who wants to have the system "just
work". So it looks pretty ugly and redundancy and whatever.

Frankly there's not so many moving parts IMHO, we don't care about the
initrd and kernel at this moment because when they are loaded and
executed, the UEFI Boot Service ended (aka they are not running in
pre-boot contect) also there's no boot sector as UEFI boot protocol
not requires it. :)


[snip]

Is there a way to eliminate a few layers of complexity? Operating
systems are supposed to be *simple*. Linus has complained about
"bloat", I know, but the hardware keeps getting better and things like
a provably secure microkernel running Linux as a guest aren't as
farfetched on a 2012-vintage quad-core x86_64 as they were on a 386.

I could understand and don't want to introduce the extra layers to
mess things further, this is why I think that's my personal idea and
not decided.

The complexity is because we want support on secure boot and not
restrict the bootloader to be SUSE-blessed. We can't make the change
on the first stage because it should be simple and bug free, neither
is the second stage as it's distribution specific so only introducing
a 1.5 layer is possible.

But I think *not running blessed bootloader" itself will have problem
as it contradict the *chian-of-trust* design of secure boot (sign).


--
Twitter: http://twitter.com/znmeb Computational Journalism Server
http://j.mp/compjournoserver

Data is the new coal - abundant, dirty and difficult to mine.

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

< Previous Next >