[Long] UEFI support

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

[Long] UEFI support

Tanguy Ortolo-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello all,

UEFI (often called EFI, which was the name of its previous version) is a
new firmware interface, which is expected to replace the BIOS on new
PCs, as at has already done so on Apple PCs. While modern operating
system do not rely much on firmware calls for normal operation, the boot
loader does.

Debian is concerned by this standard, because it has to be supported if
we want it to be usable on UEFI-based systems. And I think we should be
*very* concerned by it because, if I recall correctly, UEFI is a
requirement for the Windows 8 sticker program (“designed for Microsoft
Windows”), which means that we can expect that many branded PCs and
motherboards, if not most, will be UEFI-based.

In order not to see Debian become uninstallable (meaning, not
installable unless you are a guru) on most computers, I wonder if UEFI
support should not even be promoted as a release goal. But anyway, here
is a basic summary of how it works from a boot procedure point of view,
and what it means to support it.


UEFI boot procedure
===================

Boot manager
- ------------

First there is a boot /manager/, which is menu provided by the firmware
to select what to boot among the available systems, for instance:
    1. CD/DVD
    2. HDD1 - Microsoft Windows
    3. HDD1 - Debian GNU/Linux
    4. USB key

This is similar to the boot device selection menu that is provided by
most BIOSes, but it has been extended so that:
1. it offer a way to choose between several systems on the same device;
2. it can be configured (add, remove or reorder entries) from a running
   operating system.

A bootable system
- -----------------

In practice, a bootable system means a bootloader. On hard disks and USB
keys, contrary to BIOS which simply loads it from a fixed location, the
UEFI boot manager will load it from a file.

To be usable from the boot manager, a bootloader file has to be placed
on a supported filesystem (in practice, that means a FAT) on a partition
with an GUID corresponding to the type called “EFI System Partition”.

When it comes to the boot manager menu, there are two cases. On fixed
devices (hard disks), an entry has to be added to the menu, by
interacting with the UEFI NVRAM from a running OS using a dedicated
program. There can be several bootloaders on a single EFI System
Partition. On removable devices, such a procedure would be irrelevant,
so the boot manager will simply look for a file names
/efi/boot/boot<arch>.efi, where <arch> == {ia32|ia64|x64|arm}. Thus
there can only be a single bootloader on a removable device's EFI System
Partition.

For optical media, I am not really sure: it may use ElTorito or load a
file /efi/boot/boot<arch>.efi from the ISO-9660 or UDF filesystem, so
this should be checked.

The bootloader
- --------------

The bootloader itself has nothing specific except that is runs on an
UEFI environment and should thus use UEFI calls rather than BIOS calls,
of course.


Supporting UEFI
===============

I am taking the point of view of a user trying to install an operating
system.

Starting the installer
- ----------------------

First we need to start the installer from a removable medium. This means
having a USB key image containing a GTP with one FAT-formatted EFI
System Partition containing a boot loader at /efi/boot/boot<arch>.efi,
and possibly another partition containing whatever it takes to run the
installer.

After that, most of the installation has nothing specific, except the
following two points.

Partitionning
- -------------

We are installing an operating system to a hard disk, which may or may
not already contain an EFI System Partition.

If there is one, that partition and the content of its filesystem should
be kept (formatting it could mean removing an existing bootloader, which
would be wrong™), and it should be used later to install our bootloader.

If ther is none, it should be created and used later to install our
bootloader.

Installing the bootloader
- -------------------------

The bootloader should be installed on the EFI System Partition, on a
path following the convention /efi/<vendor>/<whaterver>, for instance
/etc/debian/grubx64.efi.

It should then be added to the boot manager menu by doing the appopriate
calls, which probably means using the appriopriate dedicated tool.


Current status
==============

This is what I think we have for Debian.

Installer image
- ---------------

I do not think we have any UEFI-bootable installer images so far.

It would be possible to create hybrid BIOS/UEFI bootable images, but
that will probably be incompatible with hybrid USB/optical images as we
have them currently. Thanks to the /efi/boot/boot<arch>.efi convention,
it would also be possible to have multiarch images.

It is also worth noting that an amd64 PC will probably support x64 UEFI
only, so given that there is probably no UEFI-base x86 PCs, there is no
point in creating corresponding images.

Partitionning
- -------------

An EFI System Partition is basically a regular partition, with a
specific type (GUID) and a FAT filesystem (or perhaps an HFS+ one on
Apple PCs).

Partman currently has two things:
1. a “bootable” flag, which may correspond to the EFI System Partition
   type;
2. an “EFI System Partition” filesystem, which may correspond to a FAT
   filesystem but does not allow to choose a mount point.

Besides, according to a user report, Partman always format a partition
you set as EFI System Partition, which is bad™.

I am not sure of how it should be presented to the user, but the right
thing to do to get a working system without dropping the possible
existing ones would be to:
1. if there is already an EFI System Partition with a supported
   filesystem, use it;
2. if there is none, create one and format it in FAT;
3. mount it under /boot/efi.

Bootloader
- ----------

I think we have three UEFI bootloader available for now: elilo, GRUB and
efilinux.

I only know GRUB because it is versatile enough to cover all my needs
(it supports BIOS, ElTorito, UEFI and PXE correctly enough for me).
Well, GRUB for UEFI can be installed as usual (grub-install /dev/sda) as
long as there is an EFI System Partition mounted on /boot/efi. It also
adds an entry to the boot manager menu if the program efibootmgr is
installed (and if it is running on a system which has been started with
UEFI, since the UEFI NVRAM is only available that way).

Anyway, the installer should detect that it has been launched from UEFI,
and try to install a bootloader such as grub-efi rather than grub-pc.
Or, if this is not possible, an explicit choice should be given to the
user.


Well, I think that was all. Thank you for reading, please comment and
let us see were that will lead us.

Some pointers for further reading:
UEFI <http://www.uefi.org/> (the spec is available but requires that you
provide your name and email address)
A blog article I wrote some time ago <http://tanguy.ortolo.eu/blog/article22/efi-boot>.

- --
 ,--.
: /` )   Tanguy Ortolo <xmpp:[hidden email]> <irc://irc.oftc.net/Tanguy>
| `-'    Debian Developer
 \_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJPBwgTAAoJEOryzVHFAGgZeK0P/2nzANkw+FPTCFZCJgA0KlJo
30Npe9vrY5A24O46LwIdkESFnZ+07H80663nmItubx81bXYOxHAO7sKKmmi0TF4/
mayGlLs4xGEc44EhgTIbJqyTeWF6y7ZGl8E6I9g2F/C6tAIvQ0g0zcHzDl7JyLKw
DqiMCsRpD7uWD2qCW6SBw5mFtuM6ouLB96izvXa3R+Qs9moZTpkI6fzWvSIkZDty
4Zcgi2CCjpoq6iMguIUueW5/uOtCRYQLQSscresWid+xpWqY0xr+OsoYFl3p4fNo
BwkXVePGG0zlh0cJBX6/WVpk+Mg2trR82ZoCtlEWANgQddrr6kG6KzMbcdHUTVXR
AXpc6CyVwzwYUtuhW93q3zDs/7xvBGsXAQ6fNDCPQeojJsdpRp98xirWwFK29OVM
ijMG6lG2oYNPFlHmVLbR1aougYpmz0v6N7vGatnZmkQ4c3wmGRBGOzlOH9cXIl5f
+yTk2THy9J9EK3UxlQ74bS0iRXiPTKzLFm+Sg9sDqCNxB0COItF2zf6WKiNxY8DL
1UetoCyM3+gYgOjFHtgYja3UUpzFJCyo4xEBlILZjHo1E+RPVaz0FYk+9eb/Mio5
s2npGIltWGev8sr4hxTt4tPX2j4NOpgKfQa2EU7p6FOxwsz9u5+G2dK5+0NBnUi8
i65PL0IORhyqpdxoeapi
=goDY
-----END PGP SIGNATURE-----


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Philipp Kern-4
Hi,

On 2012-01-06, Tanguy Ortolo <[hidden email]> wrote:
> Debian is concerned by this standard, because it has to be supported if
> we want it to be usable on UEFI-based systems. And I think we should be
> *very* concerned by it because, if I recall correctly, UEFI is a
> requirement for the Windows 8 sticker program (“designed for Microsoft
> Windows”), which means that we can expect that many branded PCs and
> motherboards, if not most, will be UEFI-based.

at least currently they still ship a compatibility mode.  With Ubuntu 64bit a
colleague of mine experienced that it did indeed boot by EFI, and installed an
appropriate grub for EFI, but the Lenovo firmware did not look in the right
places.  (It was probably only tested with the Windows bootloader.)

With Ubuntu 32bit everything worked.  Why?  Because it did not contain an
(U)EFI bootloader on the CD, and hence grub-pc was installed.  Compatibility
booting then worked as expected.  (There was also quite a bit of pain involved
in trying to get grub-pc working with amd64.  It seems the BIOS still tried
to do UEFI boots, possibly due to GPT being used by the Ubuntu installer, again
due to EFI startup.)

And note that the BIOS did not have much options, especially no option to turn
off EFI booting.  The machine in question was an Ideapad.  Please include a
boot menu option to force the installer to forget everything it knows about
EFI despite booting successfully from it, so that you can still use BIOS
compatibility (which is to many, IIRC even Linus Torvalds, still the lesser
of the two evils of x86 booting).

Kind regards
Philipp Kern


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Ben Hutchings-3
In reply to this post by Tanguy Ortolo-5
On Fri, Jan 06, 2012 at 02:41:41PM +0000, Tanguy Ortolo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello all,
>
> UEFI (often called EFI, which was the name of its previous version) is a
> new firmware interface, which is expected to replace the BIOS on new
> PCs, as at has already done so on Apple PCs. While modern operating
> system do not rely much on firmware calls for normal operation, the boot
> loader does.

As I understand it, almost all new PCs for sale today have UEFI and a
BIOS compatibility layer on top.  So this replacement has already
happened.

[...]
> In order not to see Debian become uninstallable (meaning, not
> installable unless you are a guru) on most computers, I wonder if UEFI
> support should not even be promoted as a release goal. But anyway, here
> is a basic summary of how it works from a boot procedure point of view,
> and what it means to support it.
[...]

If Debian doesn't yet fully support installation and booting on UEFI
(I haven't bought a new PC in a while so I haven't tried it) then it
should be a very high priority for the maintainers of whichever
packages are involved (installer, boot loaders, kernels).  But release
goals are usually defined for issues that involve a large number of
packages, which is not the case for UEFI support.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Johan Henriksson-2


On Fri, Jan 6, 2012 at 6:55 PM, Ben Hutchings <[hidden email]> wrote:
On Fri, Jan 06, 2012 at 02:41:41PM +0000, Tanguy Ortolo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello all,
>
> UEFI (often called EFI, which was the name of its previous version) is a
> new firmware interface, which is expected to replace the BIOS on new
> PCs, as at has already done so on Apple PCs. While modern operating
> system do not rely much on firmware calls for normal operation, the boot
> loader does.

As I understand it, almost all new PCs for sale today have UEFI and a
BIOS compatibility layer on top.  So this replacement has already
happened.

I recently set up a linux server and do see a need for linux to boot on UEFI without relying on BIOS. The reason is the limitations of the size of the booting harddrive. there are hacks around this (multiple MBRs) but these would upset for example a dual-booting windows. this also doesn't chime well when persuading new users to try out linux. so, in my opinion, debian should be among the first to support UEFI well and to show that linux can be first rate in hardware support.

one challenge for the installer will be how to support manual partitioning while making installation of the uefi boot partition easy. if there is none then debian should suggest to create it, with good default settings.

/Johan


--
-----------------------------------------------------------
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net
Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Steve Langasek
In reply to this post by Tanguy Ortolo-5
On Fri, Jan 06, 2012 at 02:41:41PM +0000, Tanguy Ortolo wrote:
> Current status
> ==============

> This is what I think we have for Debian.

> Installer image
> - ---------------

> I do not think we have any UEFI-bootable installer images so far.

I don't know if we do or not, but this seems to be a topic for discussing
with the installer team (debian-boot).

> It would be possible to create hybrid BIOS/UEFI bootable images, but
> that will probably be incompatible with hybrid USB/optical images as we
> have them currently. Thanks to the /efi/boot/boot<arch>.efi convention,
> it would also be possible to have multiarch images.

> It is also worth noting that an amd64 PC will probably support x64 UEFI
> only, so given that there is probably no UEFI-base x86 PCs, there is no
> point in creating corresponding images.

Your terminology is a bit muddled here.  If you mean "there will be no
32-bit-only systems using UEFI", that's not a safe assumption to make.
There are still 32-bit-only systems being produced, and the move from BIOS
to UEFI will affect them as well.

--
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/20120107000815.GC23208@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Tanguy Ortolo-5
Steve Langasek, 2012-01-07 01:08+0100:
>> It is also worth noting that an amd64 PC will probably support x64 UEFI
>> only, so given that there is probably no UEFI-base x86 PCs, there is no
>> point in creating corresponding images.
>
> Your terminology is a bit muddled here.  If you mean "there will be no
> 32-bit-only systems using UEFI", that's not a safe assumption to make.
> There are still 32-bit-only systems being produced, and the move from BIOS
> to UEFI will affect them as well.

This is possible indeed, but I am not sure. What kind of systems are
these exactly, before we can draw any conclusion?

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


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Steve Langasek
On Sat, Jan 07, 2012 at 10:12:15AM +0000, Tanguy Ortolo wrote:
> Steve Langasek, 2012-01-07 01:08+0100:
> >> It is also worth noting that an amd64 PC will probably support x64 UEFI
> >> only, so given that there is probably no UEFI-base x86 PCs, there is no
> >> point in creating corresponding images.

> > Your terminology is a bit muddled here.  If you mean "there will be no
> > 32-bit-only systems using UEFI", that's not a safe assumption to make.
> > There are still 32-bit-only systems being produced, and the move from BIOS
> > to UEFI will affect them as well.

> This is possible indeed, but I am not sure. What kind of systems are
> these exactly, before we can draw any conclusion?

I don't understand your question.  Are you confused about the existence of
new, consumer x86 systems with 32-bit-only processors?

--
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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Paul Wise via nm
On Sun, Jan 8, 2012 at 10:48 AM, Steve Langasek wrote:

> I don't understand your question.  Are you confused about the existence of
> new, consumer x86 systems with 32-bit-only processors?

Sounds like he was asking you to name these new 32-bit only x86
systems that are still being produced and sold.

--
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/CAKTje6FyLZVv_h8XB+WPjmzZOtLbzirOUzxOmHm_-9rJZm2kVQ@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Russell Coker
On Mon, 9 Jan 2012, Paul Wise <[hidden email]> wrote:
> Sounds like he was asking you to name these new 32-bit only x86
> systems that are still being produced and sold.

Aside from that, there is still the issue of 32bit binary-only software.

Recently I moved all the 32bit stuff I support to DomUs running on 64bit Xen
servers.  Of the current systems I run I expect to be supporting 32bit
programs for at least another year.

Buying a nice new 64bit system for the purpose of running ancient 32bit
programs at high speed is still a lot more common than we would hope.

Also note that it's not just proprietary software.  I'm running an old 32bit
MySQL installation that is extremely important to one of my clients.  It's
probably theoretically possible to just run the same database on a 64bit MySQL
installation and it's certainly possible to dump it and restore it.  But doing
that with a 24*7 mission critical database is easier said than done.

--
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/201201091108.57079.russell@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Paul Wise via nm
On Mon, Jan 9, 2012 at 8:08 AM, Russell Coker wrote:

> Aside from that, there is still the issue of 32bit binary-only software.

I would imagine that is irrelevant to this thread since you aren't
talking about bootloaders.

PS: I'm subscribed, no need to CC.

--
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/CAKTje6Gu9u7JfCn866O8oOyDEQATFDZ0_2+JF1SGd_-mCxD9Ow@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Adam Borowski-3
In reply to this post by Russell Coker
On Mon, Jan 09, 2012 at 11:08:56AM +1100, Russell Coker wrote:
> On Mon, 9 Jan 2012, Paul Wise <[hidden email]> wrote:
> > Sounds like he was asking you to name these new 32-bit only x86
> > systems that are still being produced and sold.
>
> Buying a nice new 64bit system for the purpose of running ancient 32bit
> programs at high speed is still a lot more common than we would hope.

Even worse: there's a lot of people pushing 32 bit for no obvious reason.

Go to http://ubuntu.com, look at the default download.  It's 32-bit.  Going
further, in download options, there's "32-bit (recommended)".

--
1KB // Yo momma uses IPv4!

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

Re: [Long] UEFI support

Russell Coker
In reply to this post by Paul Wise via nm
On Mon, 9 Jan 2012, Paul Wise <[hidden email]> wrote:
> > Aside from that, there is still the issue of 32bit binary-only software.
>
> I would imagine that is irrelevant to this thread since you aren't
> talking about bootloaders.

You can run a 32bit application in a chroot or in a DomU under a 64bit
environment.

But the option of having a full 32bit environment is also useful.  Admittedly
it's becomming less useful as RAM >4G is becomming more common which allows
more application address space if the kernel is 64bit.

--
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/201201091126.05938.russell@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Paul Wise via nm
On Mon, Jan 9, 2012 at 8:26 AM, Russell Coker wrote:

> You can run a 32bit application in a chroot or in a DomU under a 64bit
> environment.
>
> But the option of having a full 32bit environment is also useful.  Admittedly
> it's becomming less useful as RAM >4G is becomming more common which allows
> more application address space if the kernel is 64bit.

How is this relevant to the thread? We are talking about an
environment where Linux (or other kernel or a hypervisor) is not yet
running; there are no chroots, the running programs (GRUB, UEFI
firmware) use much less than even 500MB of RAM, let alone anywhere the
various x86 limits.

--
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/CAKTje6EBA+4-tH_MEZR1rBmp-eYsDtF9vkNOe1Fcs2OBVdxYxw@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Chow Loong Jin-3
In reply to this post by Adam Borowski-3
On 09/01/2012 08:25, Adam Borowski wrote:

> On Mon, Jan 09, 2012 at 11:08:56AM +1100, Russell Coker wrote:
>> On Mon, 9 Jan 2012, Paul Wise <[hidden email]> wrote:
>>> Sounds like he was asking you to name these new 32-bit only x86
>>> systems that are still being produced and sold.
>>
>> Buying a nice new 64bit system for the purpose of running ancient 32bit
>> programs at high speed is still a lot more common than we would hope.
>
> Even worse: there's a lot of people pushing 32 bit for no obvious reason.
>
> Go to http://ubuntu.com, look at the default download.  It's 32-bit.  Going
> further, in download options, there's "32-bit (recommended)".
Not for long. Phoronix reported[1] that on the last day of UDS, it was mentioned
that the recommended download for 12.04 will be 64-bit.

[1] http://www.phoronix.com/scan.php?page=news_item&px=MTAxMTQ
--
Kind regards,
Loong Jin


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

Re: [Long] UEFI support

Steve Langasek
In reply to this post by Adam Borowski-3
On Mon, Jan 09, 2012 at 01:25:20AM +0100, Adam Borowski wrote:
> > Buying a nice new 64bit system for the purpose of running ancient 32bit
> > programs at high speed is still a lot more common than we would hope.

> Even worse: there's a lot of people pushing 32 bit for no obvious reason.

Just because it's not obvious to you doesn't mean there aren't reasons.

On Mon, Jan 09, 2012 at 10:37:45AM +0800, Chow Loong Jin wrote:

> Not for long. Phoronix reported[1] that on the last day of UDS, it was
> mentioned that the recommended download for 12.04 will be 64-bit.

> [1] http://www.phoronix.com/scan.php?page=news_item&px=MTAxMTQ

Well, that's not very accurate.  The decision that was actually made was to
*follow up* this cycle and evaluate whether it was practical to direct users
to 64-bit images by default.  There are some power and memory penalties on
lower-end systems when running in 64-bit, which means there are still
trade-offs that need to be evaluated when choosing the default.

--
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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Tanguy Ortolo-5
In reply to this post by Paul Wise via nm
Paul Wise, 2012-01-09 00:44+0100:
> Sounds like he was asking you to name these new 32-bit only x86
> systems that are still being produced and sold.

That is right. In fact, I do not doubt there are some 32 bits only
processors sold today, but I am not sure that they are using an UEFI. It
is very possible, but it may not be a very common case.

And as some pointed it out, the problems of running 32 bits userspace
software under a 64 bits kernel is not relevant here. As far as I know,
EM64T processors still have the ability to run stuff in protected mode
even though they boot in long mode.

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


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Bjørn Mork
Tanguy Ortolo <[hidden email]> writes:
> Paul Wise, 2012-01-09 00:44+0100:
>> Sounds like he was asking you to name these new 32-bit only x86
>> systems that are still being produced and sold.
>
> That is right. In fact, I do not doubt there are some 32 bits only
> processors sold today, but I am not sure that they are using an UEFI.

There are.  STFW

> It is very possible, but it may not be a very common case.

Neither is UEFI on 64bit systems.  Yet.  So let's just ignore it then.
No?  Well, then I don't see how the "common case" argument is relevant
for 32bit systems either.


Bjørn


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

wookey-4
In reply to this post by Steve Langasek
+++ Steve Langasek [2012-01-06 16:08 -0800]:

> On Fri, Jan 06, 2012 at 02:41:41PM +0000, Tanguy Ortolo wrote:
>
> > It is also worth noting that an amd64 PC will probably support x64 UEFI
> > only, so given that there is probably no UEFI-base x86 PCs, there is no
> > point in creating corresponding images.
>
> Your terminology is a bit muddled here.  If you mean "there will be no
> 32-bit-only systems using UEFI", that's not a safe assumption to make.
> There are still 32-bit-only systems being produced, and the move from BIOS
> to UEFI will affect them as well.

ARM systems will imminently be coming out with UEFI as the primary
boot mechanism too, so at least armhf and probably armel images make
sense too.

This is actually a very good thing in the sense that we can have a
unified boot mechanism across most newish machines in the
not-too-distant future, which makes debian-boot people's lives a lot
easier.

I assume evyone here is aware of mjg's useful posts about the issue of
key-management in UEFI secure boot?

We need to do one of:

* get our bootloaders signed by something like the 'linuxfoundation key'
if such a thing gets widely installed,
* explain to users how to get the 'debian key' installed
* explain to users how to turn off secure boot.
* Get manufacturers to put the Debian key in machines for sale (or
  just make them with Debian(or a deriviative) pre-installed.

Ubuntu/Canonical probably have more leverage/interest in this aspect
of the problem so we should co-ordinate. Can be share a bootloader key
for example? - sounds sensible to me.

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/20120109140414.GA4517@...

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Tanguy Ortolo-5
Wookey, 2012-01-09 15:04+0100:

> I assume evyone here is aware of mjg's useful posts about the issue of
> key-management in UEFI secure boot?
>
> We need to do one of:
>
> * get our bootloaders signed by something like the 'linuxfoundation key'
> if such a thing gets widely installed,
> * explain to users how to get the 'debian key' installed
> * explain to users how to turn off secure boot.
> * Get manufacturers to put the Debian key in machines for sale (or
>  just make them with Debian(or a deriviative) pre-installed.

Just as a reminder, we must be aware that GRUB images are generated
locally on each host. Thus every user would have to have the secret key
to sign their boot loader image.

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


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

Reply | Threaded
Open this post in threaded view
|

Re: [Long] UEFI support

Iustin Pop-3
On Mon, Jan 09, 2012 at 04:29:12PM +0000, Tanguy Ortolo wrote:

> Wookey, 2012-01-09 15:04+0100:
> > I assume evyone here is aware of mjg's useful posts about the issue of
> > key-management in UEFI secure boot?
> >
> > We need to do one of:
> >
> > * get our bootloaders signed by something like the 'linuxfoundation key'
> > if such a thing gets widely installed,
> > * explain to users how to get the 'debian key' installed
> > * explain to users how to turn off secure boot.
> > * Get manufacturers to put the Debian key in machines for sale (or
> >  just make them with Debian(or a deriviative) pre-installed.
>
> Just as a reminder, we must be aware that GRUB images are generated
> locally on each host. Thus every user would have to have the secret key
> to sign their boot loader image.

Hmm, I might misunderstand this, but wouldn't just the grub binary need
to be signed? And this binary then would parse the grub.cfg file and
allow various kernels to boot.

regards,
iustin


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

12