[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Re: the ghost of UEFI and Micr0$0ft

On Tue, 05 Jun 2012 15:01:53 -0400, Tom H wrote:

> On Tue, Jun 5, 2012 at 1:39 PM, Camaleón <noelamac@gmail.com> wrote:


>>> http://blog.canonical.com/2011/10/28/white-paper-secure-boot-impact-
>> That white paper points to Canonical and Redhat companies.
>> I wonder if they tried to contact the other community linux members and
>> distributions or even thought about another way of handling this
>> through The Linux Foundation, for instance.
> Maybe Red Hat and Canonical contacted others, maybe they didn't. 

That's important, at leats for me. If other linux manufacturers want to 
play alone in this game, that's fine but I'd also like knowing my 
"partners" and what's their position on the subject. This UEFI issue is 
an important thing I would take with extremely care, I mean, is not like 
selecting what will be the default MUA we're going to include for the 
next release, I guess you get the point.

> These are the two Linux companies that are the least likely to
> cooperate so I'd have to guess (but it's only a guess!) that others
> were contacted.

I wonder what about SUSE (SLES and SLED) as this is another of the "big" 
linux distributors :-?

> But, if a distribution didn't react post-the-white-paper either on its
> own or in cooperation with Fedora and/or Ubuntu, then it has no right to
> complain now.

Mmmm, that's not fair: I can't react to something I'm not aware of.

> This is the position of the Linux Foundation [2] and this is the paper's
> conclusion:


> It's dated October 2011 but it doesn't seem to have a problem with what
> Fedora's done. It even calls the "establishment of an independent
> certificate authority" unnecessary.
> 2.
> https://www.linuxfoundation.org/sites/main/files/

That's an interesting insight. The sad part here starts at page 3 
("Booting closed operating systems") so, why should bother about MS 
movements if they reject to consider an open implementation of this UEFI 
secure boot?

>>> The other distributions only have themselves to blame if Fedora's
>>> ended up going its own way. I wonder what happened to Ubuntu
>>> post-the-white-paper; it's even more bizarre than the other
>>> distributions not making any kind of statement or seemingly not
>>> getting involved in fighting for Linux, given that like Fedora, Ubuntu
>>> has a new release in October/November that'll have take Secure Boot
>>> into account. Also, I suspect that had Debian's participation been
>>> raised on debian-devel, the flame war would have ended after F18 and
>>> U12.10 had been published (witness the never-ending "discussions" on
>>> replacing sysvinit that have been going on, intermittently, since last
>>> summer).
>> Maybe is that they were not properly queried for comments. And remember
>> Debian has not a time-based schedule for their releases so why should
>> we worry about the other's hurries to be more Windows-friendly?
> Debian can live in a bubble 

Which seems to be working quite fine, I'd add :-)

> by saying that it doesn't have a time-based schedule but the hardware
> manufacturers have a schedule, that of Microsoft's release of Win8. 

Are you saying that we should follow the other's (MS or harwdare 
manufacturers) schedule? Why do you think they deserve so? Have been they 
helping us in any way by open sourcing their firmaware or drivers specs? 
I think that no :-)

> So a solution has to be planned and implemented before Win8 and Secure
> Boot boxes hit the market for those distributions that choose to give
> their users the choice to use Secure Boot. 

Sorry but I don't have any hurry nor have a timeline to accomplish nor 
have shareholders to keep happy ;-)

> Debian might choose to tell its users "disable Secure Boot" as the
> second poster in this thread said, but we don't know what its choice is
> or what it's going to be.

That's exactly what I would do: teaching users is the best long-term 

Windows users with secure boot enabled who want to boot a different OS 
should ask MS how to do it, don't you think? They have paid for what they 
have installed.

> I suspect that at some point in the future not only will Secure Boot be
> extended to servers but it'll be a criterion to fulfill in order to pass
> a security audit. If a distribution doesn't get involved at the
> inception of the rules, it'll just have to live by the specs that have
> been developed and agreed to by others.

To be sincere, although I have not a deep knowledgement about this 
feature, I think it will have the same effect that DRM or TPM 
technologies... almost unuseful because they were tricky to setup with no 
value-added benefits.

>>> For those of us who want to dual-, triple-, ...-boot Windows, want to
>>> boot from a Live CD, want to compile their own kernels, want to use
>>> kernel modules not included in their distribution (assuming that the
>>> distribution can boot using Secure Boot), ..., we have to thank Fedora
>>> for working to change the spec to allow Linux to boot using Secure
>>> boot.
>> You can send them a gift ;-)
> I won't send them a gift but if Fedora's the only distribution to
> support Secure Boot, then it's the only one that I'll recommend to
> friends (independently from installing and providing support for Debian
> servers at some of my jobs) because I don't want to have to tell them
> "to install Linux or even test Linux from a CD without installing it,
> I'll have to turn off 'Secure Boot' on your computer"; they'll most
> likely say "no" anyway after hearing that.

Well, that's an option. I think I'll follow the same path I now do with 
Apple products: recommend users to run away from them and better that 
they buy a computer that is specifically "not designed for Windows 8" to 
ensure its compatibility with several operating systems and multi-boot :-)

>>> It's horrible that we'll have to go through Microsoft to boot Linux
>>> using Secure Boot but it leveraged its dominance and power to suit
>>> itself (at least in the desktop field, because in the server field,
>>> where Linux has a far more substantial presence, there's no such
>>> requirement, AFAIU). Looking at it objectively, Microsoft has
>>> manoeuvered skillfully. It would've liked to lock down x86 in the same
>>> way that it locked down ARM but knew that it would open itself to
>>> legal problems so it compromised.
>> We don't have to hold for those "horrible" things anymore. We need to
>> develop our own way. If we remain at the commands of MS we will be
>> doing it wrong.
> "We need to develop our own way" is a nice theoretical statement but do
> you have a practical, implementable solution? 

Mmm, yes. I completely removed Windows 7 Starter from my netbook, does 
that count? :-)

> If Debian were to have its own key (or if it were a member of a group
> of multiple distributions with their own shared key), it would have go
> manufacturer to manufacturer to have that key used in firmware and then
> have a hardware compatibility list. If anything, Fedora's spared us and
> itself this headache by leveraging Microsoft's power - with the
> downside that it's Microsoft that's signing the shim, stage one
> bootloader.

I prefer to keep "secure boot" off until there's an standardized and open 
way to manage this efficiently and with no other drawbacks. It's that 

>>> Lastly, Fedora's position isn't set in stone - at least not
>>> officially- because FESCO has yet to sign off on the Garrett/Jones
>>> plan (although it's a fair bet that it'll be approved). Its biggest
>>> strength is that those who are opposed to Secure Boot can simply turn
>>> it off!
>> I hope they think deeply about this decision but I'm afraid they'll
>> not.
> Think deeply it will (and probably already has), but "think deeply"
> doesn't mean what you seem to think that it means - agree with you!
> FESCO can think deeply and decide that the signed-shim plan is in the
> best interests of its users.

"In the best interests of its users"? You really think that having to 
depend on a company is something we need to be proud of?



Reply to: