Olaf Kirch and Vojtech Pavlik, two SUSE colleagues of mine that are also
kernel developers, have been looking with others at the UEFI situation
and wrote up their findings and a proposal on what to do for openSUSE.
We'll share here whatever they write, I guess they do a post a day for
the next few days.
First post is at:
http://www.suse.com/blogs/uefi-secure-boot-overview/
I'm copied the text:
In case you don’t know what this blog is talking about: UEFI is the
“Unified Extensible Firmware Interface”, and “Secure Boot” is one of its
more recent features that is generating a bit of a stir in the Open
Source world.
At SUSE, we have been looking at UEFI Secure Boot long and hard.
On one hand, we agree that closing down some of the loopholes in the
boot process is a worthwhile goal. For decades, we have accepted that
this process has been one of the soft spots that are essentially
unfixable without a major change in the BIOS. Now that this change is
coming, we are ready to embrace it. And we’re also happy to see a much
bigger change happening as part of this, which is the establishment of
UEFI as the standard firmware on all x86 platforms.
On the other hand, as a Linux company, we are seeing a number of issues
that have been causing us quite some headaches, which we wanted to
resolve before we publicly state our plans in this regard.
In order to explain our concerns, let’s take a brief look at what Secure
Boot really does, in a nutshell. In the world of UEFI, securing the
bootstrapping process means establishing a chain of trust. The
“platform” is the root of this chain of trust; I tend to think of it as
the motherboard and the on-board firmware ROM. Or, put slightly
differently, it’s the hardware vendor, and the chain of trust flows from
that hardware vendor to the component manufacturers, the OS vendors, etc.
On the legal side, this trust is established by a lot of contracts and
other legal paperwork. On the level of bits and bytes, this trust is
expressed via public key cryptography. The vendor puts a so-called
Platform Key into the ROM, representing the root of trust. The trust
relationships with operating system vendors and others is documented by
signing their keys with the Platform Key.
Finally, security is established by requiring that no code will be
executed by the firmware unless it has been signed by one of these
“trusted” keys – be it an OS boot loader, some driver located in the ROM
of some PCI Express card, or be it an update of the firmware itself.
Of course, one could make this a very long chain of trust, by requiring
that everything that ever gets run on that machine be signed: the OS
itself, the modules it loads, the binaries and shared libraries it
loads, all the scripts executed by any random interpreter, and even
the commands you type into a shell session.
So obviously, that has to stop somewhere; and in the UEFI specification,
that point is reached when the firmware hands control to the operating
system. Essentially, if you want to use Secure Boot, you need to have
your OS loader signed with a key trusted by the firmware, and you need
the OS loader to verify that the kernel it loads can be trusted.
Admittedly, this is glossing over quite some details – but that is of no
real importance for this discussion.
The crux of the matter is that this conflicts with the way the Open
Source community has been developing code for several decades now. The
Open Source movement began as an act of emancipation from the operating
system vendors of that time. Open Source was and is about Freedom, not
in a dogmatic, but really in some very practical sense. The Linux
community is where it is today because people could just start their own
distribution, build their own boot loader and kernel, and grow a
community. It is thriving the way it is thriving today because there are
thousands of people around the globe who rebuild their kernel ten times
a day to fix bugs, to add enhancements, or to run their test harness on
the latest set of changes. And it will only continue to thrive in this
way if we keep it that way.
From this point of view, Secure Boot is very much at odds with the
Linux development model.
Just for the record, I do not think this is a conspiracy, or a sinister
attempt to kill Linux. That’s not going to happen. But while Secure Boot
can be a significant improvement for many, it definitely creates
obstacles for the Linux community.
Granted, the Windows 8 Logo certification requires that BIOS vendors
should allow users to turn off Secure Boot on x86 platforms, and we have
hope that all BIOS vendors will actually implement this in a way that
works well for Linux developers. But ideally, Linux developers should
not be required to switch off a security feature in order to run their
operating system.
Thus, over the past months, our guiding questions when dealing with
Secure Boot have been, how can we make it work for our customers, and
how can we reconcile the requirements of Secure Boot with the needs of
the Linux community.
We plan to continue this series of blog postings soon with an overview
of how we intend to support Secure Boot in SUSE Linux Enterprise, and
what solutions we propose to the openSUSE community.
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi guys,
this is my first report about scanny for #1 week:
http://ruby-blog.pl/GSoC/2012/05/28/scanny-week-1/
--
Piotr Niełacny
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
Some of you know, I have recently taken a position at SUSE here in
Silicon Valley. I've joined the Sales Engineer/ SUSE Linux Technical
Specialist team. It has been a bit more than a month and I can say it
has been a really great experience.
As I am now on the "inside", I can see that SUSE has never been better
positioned to succeed in a long time. I've not had the chance to engage
the business side of SUSE before in the same way I have with the
engineering and openSUSE team side of things. That said, I've never had
the kind of welcome joining a company like I have at SUSE. It's been
extraordinary.
Because of this, I must resign from the board. I've thoroughly enjoyed
working with my fellow board members and I now consider them friends. It
does not matter if they are SUSE employees or not. They all care a lot
about the community. All my dealings with them have been very forthright
and correct.
As for me, I will not disappear from the community. Far from it. Now
that I am here in North America, I am one more voice inside the company
who will be actively evangelizing on the community's behalf. As I have
reached out to my new colleagues, there is definitely an openness to
listen, learn about and engage the community.
I could go on longer, but I do want to thank publicly Alan Clark for
helping me get on board. We as a community are really lucky to have him
as a board member and chair. Alan has done a terrific job on behalf of
the community, though often times it is quite invisible and not
recognized publicly. I've learned he has enormous respect inside SUSE
and he is a great ambassador for the community.
Thanks for listening.
Peter Linnell
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
This week, with help from Petr, and I have been going over the GPT
implementation for fdisk. Mostly dealing with newly found bugs and test
cases. So far everything looks to be going well and will probably be
sent for upstream revision in a couple of days.
This final week I plan to continue testing and, once satisfied, write
some automatic regression testing based on the scsi_debug kernel module.
Thanks,
Davidlohr
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
This is the last mail of this series.
A. Introduction
In order to get the biggest possible impact for our Release some tasks needs
to be accomplish.We in SUSE will take care of some of them and your input will
be needed in order for other to happen.
Since we do not have much time, coordination play a key role at this point. So
we would like to propose the following.
B. Proposal
In the 12.2 Public Release Action Plan wiki page[1] you can see some tasks
that we'll need your input in order to happen. In the process of getting input
for the Release Process Document, some other might arise.
We believe the best way to coordinate efforts will be to have one coordinator
for each task/group of people that put effort in each task. At SUSE we have
done the same, as you can see in the Organization Chart. This way we make sure
the communication is efficient and each group can organize as they wish.
Mailing lists, works in general, but for tight deadlines and having so many
people involved in this process, we think a person acting as point of contact
is a good improvement.
C. Example
For example:
If three people contribute doing artwork, it would be great if one of them
works as contact for this release process, making sure the communication among
the artwork contributors and other teams involved, from SUSE and the
community, works.
D. Coordination
Ludwig Nussel will add the contact data of that person in the wiki and will
make sure that we all are aware of the tasks that need to be done and the
deadlines/constrains we have. He will be our "Schedule Master" (he hates this
role :-) ).
E. Final Note
We do not expect to be perfect this first time, but there is room for
improvements during following releases. We take this as a learning process.
[1] 12.2 Release Action Plan:
http://en.opensuse.org/openSUSE:Public_Release_Action_Plan
saludos
--
Agustin Benito Bethencourt
openSUSE Team Lead at SUSE
abebe(a)suse.com
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
last week the openSUSE Team at SUSE had a meeting to discuss the proposal for
openSUSE 12.2 Release schedule made by the Release Manager. This proposal was
supported past Tuesday in a coordination meeting where managers from SUSE
involved in the process participated.
Please check the Road Map[1] wiki page to get the confirmed dates:
Basically are:
* Technical contributions freeze: August 24th 13:00 UTC
* Gold Master Declaration: August 30th
* Release date: September 5th 12:00 UTC
Please spread the word about the dates so our contributors
now them.
[1] Road Map: http://en.opensuse.org/openSUSE:Roadmap
saludos
--
Agustin Benito Bethencourt
openSUSE Team Lead at SUSE
abebe(a)suse.com
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
this is the first of three e-mails related with 12.2 Release. It deals with
the diagram done about the Release process.
A. Background
We have invest some effort in talking internally to the people from different
departments involved in openSUSE Release process to define the actions that
each one of them take to make each release happen. We have concentrate in
those that are currently happening or will need to take place the following
weeks. We having consider most of those that take place during the Candidate
release process or before that. We also haven't consider promotion activities
that we do after each release.
But above all, we haven't consider yet most of the work you guys do. Our team
is willing to receive you input, so we can analyze together how to approach
the next release trying to be even more efficient and engage even more people.
>From SUSE side, we have detected already some points of improvements and more
will arise the following weeks. We area specially interested in those actions
that we currently we do internally and can be opened and those that already
are, but for several reasons, the community cannot help us on.
This process is part of the strategy of empowering more and more, little by
little, the community in key aspects for the project.
B. The documents
We have used a simple tool (planner) to make a simple Gantt diagram with the
tasks. The goal at this point is just to have a picture of what needs to be
done and who is responsible for doing it. We will go further in following
releases, adding time lines (start and finish dates) and effort (manpower
involved) where is possible.
We are already using this document internally for managing the tasks that we
are currently doing.
C. Why we think your input is needed
This document must be accurate to be effective. Right now it only contains
SUSE vision, which is partial, of what our release process is. We want to
include those tasks you do or you participate on so it becomes useful also for
others. We believe it can become a key element in the release process
coordination in the near future.
It is also an opportunity of defining the tasks we will be doing the following
weeks to make openSUSE 12.2 happen.
Please check the openSUSE 12.2 Release Process[1] wiki page for details.
D. How to contribute
We have identified some groups of people that work on the Release in an
organized way and some other less organized. Some examples could be:
* Editors
* Translators
* Technical contributors (organized around opensuse-packaging(a)opensuse.com)
* Ambassadors
* This contributors organized around the marketing mailing list
* Artwork team
There are probably several others we are missing.
Since we are in the middle of the Release process, it would be great is those
groups name a coordinator or one person from each group steps up and give us
some input about the tasks they do during the release. Please feel free to
edit directly the wiki page and add to the table the tasks. Ludwig Nussel[2],
one of the new engineers on the openSUSE Team at SUSE will process and include
you input in the document.
If you contribute but are not organized in a group or simply prefer to use
mail instead of editing the wiki, post what you do during the release process
in this mailing list. We will discuss and include your input in the document.
It doesn't matter if you work on the technical side, marketing, artwork,
promotion.... all counts.
It is extremely important that you include as soon as possible those tasks
directly related with the Public Release phase in the 12.2 Public Release
Action Plan table[3], since we want to make sure we
don't skip them for 12.2 Release.
[1] Release Process wiki page: http://en.opensuse.org/openSUSE:Release_process
[2] Ludwig Nussel
http://en.opensuse.org/openSUSE:Release_process#Organization_chart
[3] 12.2 Public Release Action Plan:
http://en.opensuse.org/openSUSE:Public_Release_Action_Plan
Saludos
--
Agustin Benito Bethencourt
openSUSE Team Lead at SUSE
abebe(a)suse.com
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi All,
You might known we've got COSCUP at 8/18 - 8/19 - and the complete official
program list already announced, you can found it at
http://coscup.org/2012/en/program/. This mail just want to let you know what
is the current state of preparation for COSCUP. COSCUP, the largest FLOSS
conference organized by local communities in Taiwan, and it keeps grow up.
According to statistics from the registration website, this year, COSCUP will
over 1200 participants!
Collaboration
KDE and openSUSE will collaboratively organize a full two-day track at the
COSCUP this year. This time we bring a lot of exciting content, Will
Stephenson and Aaron Seigo will be cooperation in the keynote talk; Yin-Yyun
Qiao who work on Qt at Nokia will talk about new features of Qt5; Michal Chang
will introduce what changes from openSUSE 12.1 to 12.2; others topics are
cover KLyDE(lightweight KDE pattern), OBS, Akonadi, maintenance model, etc. It
sounds nice, isn't it?
openSUSE Team & Community
COSCUP 2012 is the first conference that openSUSE Team supported since rename
from Boosters Team. Will Stephenson and mine to participate COSCUP this year,
local community and us would host a booth and brings talk, the important one
is we will host a BoF at first night, chatting with local community and obtain
the feedback. About booth, we prepared some cool stuff, ex. T-Shirt[1], flyers,
stickers, Geeko doll, etc. If the entire venue can see Green Geeko, that will
be very cool!
Above is what we preparation for COSCUP, I will send a simple summary report
after end of COSCUP(with pictures :).
See you there and sorry for my poor English!
Cheers,
Max
[1] http://goo.gl/Hj8id - Thanks Ben who are t-shirt' model.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org