EFI in Debian

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

EFI in Debian

Steve McIntyre
Hey folks,

As you might have seen from recent discussions about the Fedora and
Ubuntu strategies for how to deal with EFI and Secure Boot, there are
potentially major issues in the area. In Debian we don't (yet) have a
plan, so it's high time that we had some discussion. I've set up a BoF
at DebConf for this:

https://penta.debconf.org/penta/schedule/dc12/event/925.en.html

That's Monday 9th July, 15:00 local time (21:00 UTC).

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120702164213.GC12639@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Stefano Zacchiroli
On Mon, Jul 02, 2012 at 05:42:13PM +0100, Steve McIntyre wrote:
> As you might have seen from recent discussions about the Fedora and
> Ubuntu strategies for how to deal with EFI and Secure Boot, there are
> potentially major issues in the area. In Debian we don't (yet) have a
> plan, so it's high time that we had some discussion. I've set up a BoF
> at DebConf for this:
>
> https://penta.debconf.org/penta/schedule/dc12/event/925.en.html
>
> That's Monday 9th July, 15:00 local time (21:00 UTC).

Hi Steve, thanks for taking care of that. We're indeed a bit late in our
reflections on this matter and we should come up with a plan for both
Wheezy (if still feasible?) and the future. I unfortunately won't be
able to make it for the BoF, as I've to leave shortly after DebCamp. But
I encourage everyone to participate in the BoF and please work on a
report or minutes so that we can have a discussion on list (either here
or on -boot) afterwards.

For those who are not familiar with the crux of secure boot, here are a
few recent references on the matter:

- Fedora's plans http://mjg59.dreamwidth.org/12368.html
- Ubuntu's plans
  http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/
  (with a more technical discussion of it at
   https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html )
- FSF's paper
  http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web

Cheers.
--
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Tanguy Ortolo-5
In reply to this post by Steve McIntyre
Steve McIntyre, 2012-07-02 18:42+0200:
> As you might have seen from recent discussions about the Fedora and
> Ubuntu strategies for how to deal with EFI and Secure Boot, there are
> potentially major issues in the area. In Debian we don't (yet) have a
> plan, so it's high time that we had some discussion. I've set up a BoF
> at DebConf for this:

I cannot attend, but hoping it can be useful, here are some pointers to
things I wrote some time ago on this subject.

A blog post explaining how to set up Debian to boot via UEFI:
    http://tanguy.ortolo.eu/blog/article51/debian-efi
A message to this list detailing the UEFI boot procedure and what is
required to support it:
    <je7174$b6p$[hidden email]>
    http://lists.debian.org/debian-devel/2012/01/msg00168.html

--
 ,--.
: /` )   Tanguy Ortolo      <xmpp:[hidden email]>
| `-'    Debian Developer   <irc://irc.oftc.net/Tanguy>
 \_


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/jt1c0d$qn1$1@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Tanguy Ortolo-5
Tanguy Ortolo, 2012-07-04 14:13+0200:
> A blog post explaining how to set up Debian to boot via UEFI:
>    http://tanguy.ortolo.eu/blog/article51/debian-efi
> A message to this list detailing the UEFI boot procedure and what is
> required to support it:
>    <je7174$b6p$[hidden email]>
>    http://lists.debian.org/debian-devel/2012/01/msg00168.html

(basically, we already have everything needed to boot via UEFI (not with
SecureBoot of course, though), only the Debian installer does not
support it)

--
 ,--.
: /` )   Tanguy Ortolo      <xmpp:[hidden email]>
| `-'    Debian Developer   <irc://irc.oftc.net/Tanguy>
 \_


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/jt1e7k$fik$1@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Steve McIntyre
In reply to this post by Tanguy Ortolo-5
Tanguy wrote:

>Steve McIntyre, 2012-07-02 18:42+0200:
>> As you might have seen from recent discussions about the Fedora and
>> Ubuntu strategies for how to deal with EFI and Secure Boot, there are
>> potentially major issues in the area. In Debian we don't (yet) have a
>> plan, so it's high time that we had some discussion. I've set up a BoF
>> at DebConf for this:
>
>I cannot attend, but hoping it can be useful, here are some pointers to
>things I wrote some time ago on this subject.
>
>A blog post explaining how to set up Debian to boot via UEFI:
>    http://tanguy.ortolo.eu/blog/article51/debian-efi
>A message to this list detailing the UEFI boot procedure and what is
>required to support it:
>    <je7174$b6p$[hidden email]>
>    http://lists.debian.org/debian-devel/2012/01/msg00168.html

Cool, thanks for the pointers. If you can make it, please try to join
the session via video and irc?

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/E1SmsQ0-0005px-46@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Theodore Y. Ts'o
In reply to this post by Tanguy Ortolo-5
On Wed, Jul 04, 2012 at 12:51:01PM +0000, Tanguy Ortolo wrote:

> Tanguy Ortolo, 2012-07-04 14:13+0200:
> > A blog post explaining how to set up Debian to boot via UEFI:
> >    http://tanguy.ortolo.eu/blog/article51/debian-efi
> > A message to this list detailing the UEFI boot procedure and what is
> > required to support it:
> >    <je7174$b6p$[hidden email]>
> >    http://lists.debian.org/debian-devel/2012/01/msg00168.html
>
> (basically, we already have everything needed to boot via UEFI (not with
> SecureBoot of course, though), only the Debian installer does not
> support it)

James Bottomly has been doing some work to support Secure Boot.  See:

      http://lwn.net/Articles/503820/

His work was done specifically to help other community distributions
beyond Ubuntu and Fedora.  We (the LF Technical Advisory Board) are
currently investigating if there is more the LF can do to support
distributions.  We're not in the position to promise anything just
yet, but if Debian has any suggestions of things that you might like,
do please let me know.

Regards,

                                                - Ted


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120706022737.GA9783@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Ben Hutchings-3
On Thu, 2012-07-05 at 22:27 -0400, Theodore Ts'o wrote:

> On Wed, Jul 04, 2012 at 12:51:01PM +0000, Tanguy Ortolo wrote:
> > Tanguy Ortolo, 2012-07-04 14:13+0200:
> > > A blog post explaining how to set up Debian to boot via UEFI:
> > >    http://tanguy.ortolo.eu/blog/article51/debian-efi
> > > A message to this list detailing the UEFI boot procedure and what is
> > > required to support it:
> > >    <je7174$b6p$[hidden email]>
> > >    http://lists.debian.org/debian-devel/2012/01/msg00168.html
> >
> > (basically, we already have everything needed to boot via UEFI (not with
> > SecureBoot of course, though), only the Debian installer does not
> > support it)
>
> James Bottomly has been doing some work to support Secure Boot.  See:
>
>       http://lwn.net/Articles/503820/
>
> His work was done specifically to help other community distributions
> beyond Ubuntu and Fedora.  We (the LF Technical Advisory Board) are
> currently investigating if there is more the LF can do to support
> distributions.  We're not in the position to promise anything just
> yet, but if Debian has any suggestions of things that you might like,
> do please let me know.
UEFI running in qemu is likely to be very useful for development of UEFI
support by the Debian installer and Debian CD teams.

Secure Boot is another matter, which I was planning to raise *after* the
release as it's controversial and I don't think we have time to do
anything about it for wheezy.  But here's what I think we would need:

1. General consensus in the project that supporting the option of Secure
Boot, including purchase of a Microsoft-signed certificate, is
worthwhile and not entirely objectionable.  (I am assuming that it would
be a waste of time to use our own platform key, as anyone who can work
out how to install that can also disable Secure Boot.)

2. Upstream kernel support: when booted in Secure Boot mode, Linux would
only load signed kernel modules and disable the various debug interfaces
that allow code injection.  I'm aware that David Howells, Matthew
Garrett and others are working on this.

3. A suitable free boot loader: when booted in Secure Boot mode it would
only load signed EFI executables.  There seem to be several projects
under way to do this.

4. EFI code signing tool.  Matthew Garrett seems to have that in hand.

5. Key management policy.  Similar issues to archive signing keys, but
these keys also need to be available at build time.  (a) Should they be
held by package maintainers and/or the auto-builders for the relevant
architectures?  (b) sbuild and/or pbuilder will need to know how to
inject them into the build environment for the relevant packages.  (c)
How do we handle key replacement when exploitable code needs to be
blacklisted?

6. User documentation: users need to be informed that when running Linux
under Secure Boot some major features are disabled, and that they have
the option to turn it off.  (Or install their own platform key.)

So, returning to your question: I think that LF may be able to help with
5(c), 6, and perhaps 3 (encouraging more coordinated development).

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Josselin Mouette
Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit :
> 1. General consensus in the project that supporting the option of Secure
> Boot, including purchase of a Microsoft-signed certificate, is
> worthwhile and not entirely objectionable.  

Not entirely objectionable indeed, but it really depends on what we
would have to pay for.  As long as it is only covering for
administrative costs of Microsoft emitting a new certificate, it is
fine.  If OTOH we have to pay a fee just for our software to work on
platforms that just happen to be using Microsoft’s certificate, this is
clearly abusive.  I would object to do so, and I believe we would (at
least in Europe) have a very strong case in court against such practice.

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1341562441.21607.269.camel@pi0307572

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Carlos Alberto Lopez Perez
In reply to this post by Ben Hutchings-3
On 06/07/12 06:32, Ben Hutchings wrote:
> 1. General consensus in the project that supporting the option of Secure
> Boot, including purchase of a Microsoft-signed certificate, is
> worthwhile and not entirely objectionable.  (I am assuming that it would
> be a waste of time to use our own platform key, as anyone who can work
> out how to install that can also disable Secure Boot.)
>

This are the FSF recommendations:

http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web



Regards!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez                           http://neutrino.es
Igalia - Free Software Engineering                http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Paul Wise via nm
On Fri, Jul 6, 2012 at 5:41 AM, Carlos Alberto Lopez Perez wrote:

> This are the FSF recommendations:
>
> http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web

These seem much more in line with the Debian social contract than any
the actions of other distributions or of the suggestions we have had.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CAKTje6GDau-v4bB4xwwPcGSPn0NEOFPR0O4vFzeGQCxQXJDRyQ@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Ansgar Burchardt-8
In reply to this post by Ben Hutchings-3
Hi,

Ben Hutchings <[hidden email]> writes:
> 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> only load signed kernel modules and disable the various debug interfaces
> that allow code injection.  I'm aware that David Howells, Matthew
> Garrett and others are working on this.

That makes dkms modules unusable when using secure boot.  I guess we
would have to build binary packages for all supported kernel versions?

> 5. Key management policy.  Similar issues to archive signing keys, but
> these keys also need to be available at build time.  (a) Should they be
> held by package maintainers and/or the auto-builders for the relevant
> architectures?  (b) sbuild and/or pbuilder will need to know how to
> inject them into the build environment for the relevant packages.  (c)
> How do we handle key replacement when exploitable code needs to be
> blacklisted?

Do these need to be available when building the kernel packages or would
it be possible to have the signatures in a separate package?  The latter
would allow moving the signing off the auto-builders and having either
a human maintainer or a dedicated system do so instead (so the
auto-builders would not need access to the keys).  It would also allow
signing modules provided in the maintainer upload.

Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87k3yfoci0.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Ben Hutchings-3
On Sat, 2012-07-07 at 08:46 -0600, Ansgar Burchardt wrote:

> Hi,
>
> Ben Hutchings <[hidden email]> writes:
> > 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> > only load signed kernel modules and disable the various debug interfaces
> > that allow code injection.  I'm aware that David Howells, Matthew
> > Garrett and others are working on this.
>
> That makes dkms modules unusable when using secure boot.  I guess we
> would have to build binary packages for all supported kernel versions?
The Linux kernel hardly has a perfect security record, but signing code
that is too bad even for staging will be a quick route to blacklisting.
I would absolutely oppose signing out-of-tree modules with Debian keys.

> > 5. Key management policy.  Similar issues to archive signing keys, but
> > these keys also need to be available at build time.  (a) Should they be
> > held by package maintainers and/or the auto-builders for the relevant
> > architectures?  (b) sbuild and/or pbuilder will need to know how to
> > inject them into the build environment for the relevant packages.  (c)
> > How do we handle key replacement when exploitable code needs to be
> > blacklisted?
>
> Do these need to be available when building the kernel packages or would
> it be possible to have the signatures in a separate package?
That is possible... but the installation process would be tricky.

> The latter
> would allow moving the signing off the auto-builders and having either
> a human maintainer or a dedicated system do so instead (so the
> auto-builders would not need access to the keys).  It would also allow
> signing modules provided in the maintainer upload.

It would also help sites to sign with their own PK, if they want to take
full advantage of Secure Boot.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Steve Langasek
In reply to this post by Josselin Mouette
On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit :
> > 1. General consensus in the project that supporting the option of Secure
> > Boot, including purchase of a Microsoft-signed certificate, is
> > worthwhile and not entirely objectionable.  

> Not entirely objectionable indeed, but it really depends on what we
> would have to pay for.  As long as it is only covering for
> administrative costs of Microsoft emitting a new certificate, it is
> fine.

Microsoft has indicated their intent to provide the Secure Boot CA services
free of charge.  AIUI the only associated fee is to a third party, Verisign,
for them to provide the service of establishing digital identity to
Microsoft's standards.

> If OTOH we have to pay a fee just for our software to work on platforms
> that just happen to be using Microsoft’s certificate, this is clearly
> abusive.  I would object to do so, and I believe we would (at least in
> Europe) have a very strong case in court against such practice.

Note that the Windows 8 requirements stipulate that users must in all cases
retain the ability to disable Secure Boot on their x86 systems from the
firmware.  It's really a question of ease of installation, and whether
Secure Boot provides any additional security protection that we think it's
worth providing to Debian users out of the box.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Andreas Barth-6
* Steve Langasek ([hidden email]) [120707 22:54]:

> On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > If OTOH we have to pay a fee just for our software to work on platforms
> > that just happen to be using Microsoft’s certificate, this is clearly
> > abusive.  I would object to do so, and I believe we would (at least in
> > Europe) have a very strong case in court against such practice.
>
> Note that the Windows 8 requirements stipulate that users must in all cases
> retain the ability to disable Secure Boot on their x86 systems from the
> firmware.  It's really a question of ease of installation, and whether
> Secure Boot provides any additional security protection that we think it's
> worth providing to Debian users out of the box.

IIRC it's not the same on embedded hardware.


Andi


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120707210957.GG2385@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Stefano Zacchiroli
In reply to this post by Steve Langasek
On Sat, Jul 07, 2012 at 02:48:59PM -0600, Steve Langasek wrote:

> On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > If OTOH we have to pay a fee just for our software to work on platforms
> > that just happen to be using Microsoft’s certificate, this is clearly
> > abusive.  I would object to do so, and I believe we would (at least in
> > Europe) have a very strong case in court against such practice.
>
> Note that the Windows 8 requirements stipulate that users must in all cases
> retain the ability to disable Secure Boot on their x86 systems from the
> firmware.  It's really a question of ease of installation, and whether
> Secure Boot provides any additional security protection that we think it's
> worth providing to Debian users out of the box.
This argument seems to depend on how thoroughly Microsoft will enforce
their Windows 8 requirements. AFAIU, the fact that Windows 8
requirements might, at least theoretically, be disattended is something
that played a role also in Canonical/Ubuntu decision to stay away from
Grub. All in all, it doesn't seem wise to rely on the fact that Windows
8 requirements will be enforced, especially when disattending them gives
an advantage to Microsoft, by making it even harder to install other
OSs.

Cheers.
--
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Steve Langasek
In reply to this post by Andreas Barth-6
On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote:
> * Steve Langasek ([hidden email]) [120707 22:54]:
> > On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > > If OTOH we have to pay a fee just for our software to work on platforms
> > > that just happen to be using Microsoft’s certificate, this is clearly
> > > abusive.  I would object to do so, and I believe we would (at least in
> > > Europe) have a very strong case in court against such practice.

> > Note that the Windows 8 requirements stipulate that users must in all cases
> > retain the ability to disable Secure Boot on their x86 systems from the
> > firmware.  It's really a question of ease of installation, and whether
> > Secure Boot provides any additional security protection that we think it's
> > worth providing to Debian users out of the box.

> IIRC it's not the same on embedded hardware.

The distinction is between x86 and ARM, and the Windows 8 cert requirements
for ARM appear to have as their goal to prevent any other OS to be bootable
on that hardware.  So I don't think you should expect MS to sign any UEFI
ARM bootloader binaries at all.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120707215813.GB24468@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

wookey-4
+++ Steve Langasek [2012-07-07 15:58 -0600]:
> On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote:
 > > * Steve Langasek ([hidden email]) [120707 22:54]:

> > > On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > > > If OTOH we have to pay a fee just for our software to work on platforms
> > > > that just happen to be using Microsoft’s certificate, this is clearly
> > > > abusive.  I would object to do so, and I believe we would (at least in
> > > > Europe) have a very strong case in court against such practice.
>
> > > Note that the Windows 8 requirements stipulate that users must in all cases
> > > retain the ability to disable Secure Boot on their x86 systems from the
> > > firmware.  It's really a question of ease of installation, and whether
> > > Secure Boot provides any additional security protection that we think it's
> > > worth providing to Debian users out of the box.
>
> > IIRC it's not the same on embedded hardware.
>
> The distinction is between x86 and ARM, and the Windows 8 cert requirements
> for ARM appear to have as their goal to prevent any other OS to be bootable
> on that hardware.

Which is pretty outrageous IMHO and may well become a serious problem
once PC-like ARM hardware becomes widely available (laptops and
capable tablets). It is very disappointing that once they agreed to
free-up x86 everyone said, 'oh that's alright then', failing to
appreciate that ARM hardware will (likely) be just as ubiquitous as
x86 quite soon. Hopefully enough people will produce hardware that
isn't crippled in this way, but if Windows 8 is a popular platform one
may get a greatly restricited choice.

Will Android machines make secure boot turn-offable or another key
installable, or will thay follow the Microsoft lead and lock
everything down too?

A competition case is much harder to bring here because Windows has
almost zero share on ARM and can use that as an excuse. Of course, as
we know in Debian architecture is really irrelevant to the question of
'is this OS dominant and using its dominance in one area to restrict
competition in another'? This makes the ARM/x86 distinction in the
rules a devious scheme to reduce competition, which seems to be
working so far (and in our case prevent us using such computers
usefully at all).

In an ideal world the fact that can't unlock your device and install
another OS will be seen as a consumer disadvantage and reduce the
supply of hardware with no ability to install alternate keys, but that
seems an unlikely outcome, as most people don't care, or won't until
it's too late.

I'm not sure what we can actually do about this technically.
Approximately nothing, except look for ways to hack the secure boot
mechanism on interesting hardware.

I can't recall if the rules for arm actually prevent the bootloader
allowing the loading of other keys, or just prevent turning off secure
boot. I think the latter, but as there is no requirement for this
feature it may be rare in practice. By making this easily available in
UEFI I suppose that may encourage manufacturers to enable it.

> So I don't think you should expect MS to sign any UEFI
> ARM bootloader binaries at all.

Quite.

Wookey
--
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120708131523.GY13768@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Russell Coker
On Sun, 8 Jul 2012, Wookey <[hidden email]> wrote:

> > The distinction is between x86 and ARM, and the Windows 8 cert
> > requirements for ARM appear to have as their goal to prevent any other
> > OS to be bootable on that hardware.
>
> Which is pretty outrageous IMHO and may well become a serious problem
> once PC-like ARM hardware becomes widely available (laptops and
> capable tablets). It is very disappointing that once they agreed to
> free-up x86 everyone said, 'oh that's alright then', failing to
> appreciate that ARM hardware will (likely) be just as ubiquitous as
> x86 quite soon. Hopefully enough people will produce hardware that
> isn't crippled in this way, but if Windows 8 is a popular platform one
> may get a greatly restricited choice.

I expect that by most metrics Android phones outsell PCs nowadays (largely
because phone contracts encourage replacement every 2 years and some portion
of the phones break before then).  A significant portion of the Android phones
sold are locked down such that you can't change which version of the kernel
you run and can't get root access in any reasonable manner.

The iPhone has a comparable market volume to Android phones and is uniformly
locked down.

In terms of making ARM systems less free it doesn't seem to me that the MS
initiative in this regard is making things much worse than they are at the
moment.

Also it should be noted that while porting Linux to an ARM device designed for
Windows (such as a Windows phone) would probably take a lot of work it's
relatively easy to get your own Linux build on an Android phone if it's not
locked down.

--
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/201207090034.03088.russell@...

Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Ben Hutchings-3
In reply to this post by wookey-4
On Sun, 2012-07-08 at 14:15 +0100, Wookey wrote:
[...]
> A competition case is much harder to bring here because Windows has
> almost zero share on ARM and can use that as an excuse. Of course, as
> we know in Debian architecture is really irrelevant to the question of
> 'is this OS dominant and using its dominance in one area to restrict
> competition in another'?
[...]

It's not irrelevant.  OS dominance is dependent on relationships with
hardware manufacturers (not the same for different architectures) and
application developers (often uninterested in porting, however easy it
is).

Did Windows NT take over PowerPC?  No.  Alpha?  Not even after FX!32
provided fast x86 emulation.

And the application developers used to Win32 (or Windows Forms) won't be
able to port to Windows RT without first rewriting for the 'Windows
Runtime' APIs.

Ben.

--
Ben Hutchings
Life would be so much easier if we could look at the source code.

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EFI in Debian

Paul Wise via nm
In reply to this post by wookey-4
On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> Will Android machines make secure boot turn-offable or another key
> installable, or will thay follow the Microsoft lead and lock
> everything down too?

Are there any Android devices that aren't *already* bootloader locked
or require jailbreaking to get root? I don't think Microsoft is
creating a trend here, locked down ARM devices are already the norm
AFAICT.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CAKTje6E1EdC87S6FTXffJ1HVr4SpoBXTcoh6ENXgvq3BRQhK8g@...

12