Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
On Fri, 2012-07-06 at 11:02 +0200, Bastian Blank wrote: > On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote: > > The fundamental problem we must solve is allowing the *user* to > > securely choose which OS she wants to install. > > No. The user can disable secure boot. > > > Whether that OS > > follows thru and verifies all its parts is between the user and the > > person or group who provided the OS (could be the user, herself, of > > course!) > > No, this is not voluntary. If we get a loader signed by an external > entity, it have to fulfill the requirements, aka no execution of > unsigned code in the kernel. That was my first reaction. But I'm not sure it's correct. > > Would this work? What have I missed? > > You show a fundamental missinterpretation of the goals of secure boot. I > see nothing worth commenting on. The goal is to prevent malware from persistently subverting a legitimate OS kernel, even if it tricks the user or the kernel into letting it install a boot loader or kernel module. So, if some hypothetical boot loader handles the appearance of some unsigned boot payload by asking 'do you really want to boot this?', of course the naive user will answer 'yes, I want to boot my computer'. Malware will then use that boot loader as its first stage and it will end up blacklisted. However, if the process of making the hypothetical boot loader trust new boot code involves a more active decision on the user's part (and if that decision cannot be automated by malware), it might possibly be sufficient to keep it from being exploited and blacklisted. But perhaps there are formal requirements that I'm not aware of, that would still forbid this. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote: > The fundamental problem we must solve is allowing the *user* to > securely choose which OS she wants to install. No. The user can disable secure boot. > Whether that OS > follows thru and verifies all its parts is between the user and the > person or group who provided the OS (could be the user, herself, of > course!) No, this is not voluntary. If we get a loader signed by an external entity, it have to fulfill the requirements, aka no execution of unsigned code in the kernel. > Would this work? What have I missed? You show a fundamental missinterpretation of the goals of secure boot. I see nothing worth commenting on. Bastian -- The man on tops walks a lonely street; the "chain" of command is often a noose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706090215.gb19...@wavehammer.waldi.eu.org
Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
On Fri, 6 Jul 2012, Rick Thomas wrote: > We need a "stage-1" boot loader, signed by somebody trusted (FSF? > SFLC?) with a key that will be recognized by the SecureBoot BIOS. > This is an un-changable binary blob, so it can't be GPL (is this a > problem?) There is no reason why GPL source can't be used for an unchangable binary. As long as the source is supplied then it's not a problem. Every Debian package is an unchangable binary, we don't change binaries we just replace them with newer versions. There is a huge range of embedded devices with the Linux kernel (and other GPL software) in ROM which almost never get updated. A Linux kernel in a mobile phone which has a locked boot loader is no different in terms of license from a secure boot loader under the GPL. Using GPL licensed software to enforce signature checks is not a problem either. We have GPG (and many other programs) for checking signatures and doing encryption and we have SE Linux (and many other options) for access control. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207061458.32921.russ...@coker.com.au
Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
The fundamental problem we must solve is allowing the *user* to securely choose which OS she wants to install. Whether that OS follows thru and verifies all its parts is between the user and the person or group who provided the OS (could be the user, herself, of course!) We need a "stage-1" boot loader, signed by somebody trusted (FSF? SFLC?) with a key that will be recognized by the SecureBoot BIOS. This is an un-changable binary blob, so it can't be GPL (is this a problem?) but at least we can publish the source code, and anybody who wants to can verify that the blob is the result of compiling that source code. Whoever did the original signing can publish signed updated blobs in the future if changes become necessary or desirable. Hopefully, the limited functionality in the original version will be enough to get the job done so changes will be infrequent to non- existent. The stage-1 boot loader blob has the following functionality: 1) It can ask the user to enter a password, which it hashes into a the private half of a cryptographic signing key. Without the user's password, the private half of the key is unknowable. The public half of the key is, of course, freely available and should be cached in some kind of write-once/read-many memory if such is available (You can buy USB keys with a physical write-enable switch. Would something like that be good for this application? Does the UEFI API have a way of stashing such a thing along with its keys?) 2) It can keep a cache of (location, description, signature) triplets for stage-2 bootloaders in some place where it can be retrieved without further user intervention. Would the boot block be a good place? The cache will be publicly readable -- and writable -- so it needs to be signed by the private part of the user's key, and verifiable with the public part of that key. 3) When it's loaded by the UEFI bios, it reads the cache and verifies the signature using the public part of the user's key. Based on keyboard input (or lack thereof, after a short timeout) it picks one entry from the cache and loads that stage-2 boot loader, verifies its signature, and pass control to it. 4) Other things the user can do if she has access to the keyboard before the time-out expires: a) Request a menu of, and choose one of, the available stage-2 boot loaders, taken from the description part of the cached triplets. b) Designate one from the above menu as the "default" for future boots if the timeout expires. c) Request to add a new entry to the stage-2 boot loaders cache, providing the location and description. It then requests and verifies the user's password and uses it to compute the signature of the new stage-2, then sign and write the modified cache. d) Request deletion of a cache entry. It then requests and verifies the user's password and uses it to sign and write the modified cache. e) Request to change her password, providing the old password as verification of her right to do so. f) Request to chain-load another stage-1 boot loader from removable media. This program would need to be signed with one of the keys known to the SecureBoot BIOS, or, if not, have explicit permission to be loaded from the user at the keyboard. This is the rat-hole we provide for installation of new OS's. Would this work? What have I missed? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/38b1a676-40d9-4c0d-9dbb-6b50b533e...@pobox.com
Re: [Long] UEFI support
On Mon, Jan 09, 2012 at 08:01:00PM +, Philip Hands wrote: > On Mon, 9 Jan 2012 14:04:15 +, Wookey wrote: [...] > > * 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. > > Are we going to have a restricted-GRUB that is only willing to load > kernels also signed by keys built into it, which in turn are configured > not to do tricks like kexec, to ensure that one doesn't use linux as a > bootloader? I think we would have to provide both options: a signed GRUB that only boots signed kernels, and an unsigned GRUB that is unrestricted. (Similarly for other UEFI bootloaders.) Don't ask me how we build the signed binaries, though. In any case, I wouldn't expect the public key (KEK) for the bootloader to be preinstalled except on systems that ship with Debian. But the Linux Foundation proposal envisages that a fresh system should allow the OS installer to install a KEK and the firmware should provide a 'reset to factory default' that allows this again. > If not, then any signature on GRUB will just be an invitation to some > scrote to use that signed GRUB as part of their rootkit to insert > malware under windows, and give Microsoft a nice headline about us lot > of pinko-commies being the cause of their latest security problems. [...] Exactly. Indeed, I have heard that some Windows rootkits already use GRUB. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109202804.gr20...@decadent.org.uk
Re: [Long] UEFI support
On Mon, Jan 09, 2012 at 07:04:49PM +, Tanguy Ortolo wrote: > Iustin Pop, 2012-01-09 19:57+0100: > > 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. > > Negative. Or rather, at least not the way GRUB currently works, since it > embeds in its core image just the modules required to access the file > system where it will find its configuration and all its other modules. In any case, GRUB allows loading arbitrary payloads and that defeats the whole purpose of Secure Boot. You either have to do signature checking all the way (bootloader checks kernel; kernel checks modules) or disable Secure Boot. The Linux Foundation and Red Hat separately issued statements on how they think OEMs should implement Secure Boot so as to support free operating systems and user choice: http://lwn.net/Articles/464819/ Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109201718.gq20...@decadent.org.uk
Re: [Long] UEFI support
On Mon, 9 Jan 2012 14:04:15 +, Wookey wrote: > +++ Steve Langasek [2012-01-06 16:08 -0800]: > > On Fri, Jan 06, 2012 at 02:41:41PM +, 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. Are we going to have a restricted-GRUB that is only willing to load kernels also signed by keys built into it, which in turn are configured not to do tricks like kexec, to ensure that one doesn't use linux as a bootloader? If not, then any signature on GRUB will just be an invitation to some scrote to use that signed GRUB as part of their rootkit to insert malware under windows, and give Microsoft a nice headline about us lot of pinko-commies being the cause of their latest security problems. For people that are serious about making machines secure boot Linux, what they need to be able to do is, firstly discard all the pre-installed keys (since it's only a matter of time before one of those is compromised) and then install their own locally generated key(s) with which they then sign the version of GRUB they prefer, which they should probably have configured to only boot kernels they trust, etc. etc. For Joe Average, who is going to struggle to find the BIOS setup on a current machine, well, I think MS just killed any chance of them trying Linux on new machines, unless someone like Neelie Kroes does something aggressive about this in a hurry. I'm wondering just how big the middle ground is: those that can find the BIOS, cannot do their own key management, and are scared to untick the "Secure" box when they read the Debian install notes (assuming any of those options exist) -- I have a feeling that that's going to be quite a small proportion of our potential users, so having a distro key seems like it's not too worthwhile, and has the potential for some seriously bad publicity. On the other hand, all publicity is supposed to be good publicity ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp0IbSuPqGr4.pgp Description: PGP signature
Re: [Long] UEFI support
Iustin Pop, 2012-01-09 19:57+0100: > 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. Negative. Or rather, at least not the way GRUB currently works, since it embeds in its core image just the modules required to access the file system where it will find its configuration and all its other modules. -- ,--. : /` ) Tanguy Ortolo | `-'Debian Developer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jefdoh$d84$1...@dough.gmane.org
Re: [Long] UEFI support
On Mon, Jan 09, 2012 at 04:29:12PM +, 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109185753.ga4...@teal.hq.k1024.org
Re: [Long] UEFI support
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 | `-'Debian Developer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jef4ko$9cl$1...@dough.gmane.org
Re: [Long] UEFI support
+++ Steve Langasek [2012-01-06 16:08 -0800]: > On Fri, Jan 06, 2012 at 02:41:41PM +, 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109140414.ga4...@dream.aleph1.co.uk
Re: [Long] UEFI support
Tanguy Ortolo 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vlhfei7@nemi.mork.no
Re: [Long] UEFI support
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 | `-'Debian Developer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jee663$uqj$1...@dough.gmane.org
Re: [Long] UEFI support
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Long] UEFI support
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 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 Description: OpenPGP digital signature
Re: [Long] UEFI support
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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6eba+4-th_mezr1rbmp-eysdtf9vknoe1fcs2obvdx...@mail.gmail.com
Re: [Long] UEFI support
On Mon, 9 Jan 2012, Paul Wise 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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201091126.05938.russ...@coker.com.au
Re: [Long] UEFI support
On Mon, Jan 09, 2012 at 11:08:56AM +1100, Russell Coker wrote: > On Mon, 9 Jan 2012, Paul Wise 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 Description: Digital signature
Re: [Long] UEFI support
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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gu9u7jfcn866o8ooydeqatfdz0_2+jf1sgd_-mcxd...@mail.gmail.com
Re: [Long] UEFI support
On Mon, 9 Jan 2012, Paul Wise 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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201091108.57079.russ...@coker.com.au
Re: [Long] UEFI support
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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6fylzvv_h8xb+wpjmzzotlbzirouzxomhm_-9rjzm2...@mail.gmail.com
Re: [Long] UEFI support
On Sat, Jan 07, 2012 at 10:12:15AM +, 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Long] UEFI support
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 | `-'Debian Developer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/je95pv$8a8$1...@dough.gmane.org
Re: [Long] UEFI support
On Fri, Jan 06, 2012 at 02:41:41PM +, 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.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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120107000815.gc23...@virgil.dodds.net
Re: [Long] UEFI support
On Fri, Jan 6, 2012 at 6:55 PM, Ben Hutchings wrote: > On Fri, Jan 06, 2012 at 02:41:41PM +, 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
Re: [Long] UEFI support
On Fri, Jan 06, 2012 at 02:41:41PM +, 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120106175527.gm20...@decadent.org.uk
Re: [Long] UEFI support
Hi, On 2012-01-06, Tanguy Ortolo 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjge2s4.udt.tr...@kelgar.0x539.de
[Long] UEFI support
-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.efi, where == {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.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.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//, 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.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 r
