Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

2012-07-06 Thread Ben Hutchings
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. > > >

Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

2012-07-06 Thread Bastian Blank
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 an

Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

2012-07-05 Thread Russell Coker
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 b

Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

2012-07-05 Thread Rick Thomas
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 "sta

Re: [Long] UEFI support

2012-01-09 Thread Ben Hutchings
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' install

Re: [Long] UEFI support

2012-01-09 Thread Ben Hutchings
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.

Re: [Long] UEFI support

2012-01-09 Thread Philip Hands
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-

Re: [Long] UEFI support

2012-01-09 Thread Tanguy Ortolo
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 it

Re: [Long] UEFI support

2012-01-09 Thread Iustin Pop
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 t

Re: [Long] UEFI support

2012-01-09 Thread Tanguy Ortolo
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, > * explai

Re: [Long] UEFI support

2012-01-09 Thread Wookey
+++ 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 correspondin

Re: [Long] UEFI support

2012-01-09 Thread Bjørn Mork
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 the

Re: [Long] UEFI support

2012-01-08 Thread Tanguy Ortolo
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

Re: [Long] UEFI support

2012-01-08 Thread Steve Langasek
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 be

Re: [Long] UEFI support

2012-01-08 Thread Chow Loong Jin
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 s

Re: [Long] UEFI support

2012-01-08 Thread Paul Wise
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 allo

Re: [Long] UEFI support

2012-01-08 Thread Russell Coker
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 environmen

Re: [Long] UEFI support

2012-01-08 Thread Adam Borowski
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

Re: [Long] UEFI support

2012-01-08 Thread Paul Wise
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/

Re: [Long] UEFI support

2012-01-08 Thread Russell Coker
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 64b

Re: [Long] UEFI support

2012-01-08 Thread Paul Wise
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 so

Re: [Long] UEFI support

2012-01-08 Thread Steve Langasek
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 imag

Re: [Long] UEFI support

2012-01-07 Thread Tanguy Ortolo
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 wi

Re: [Long] UEFI support

2012-01-06 Thread Steve Langasek
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 b

Re: [Long] UEFI support

2012-01-06 Thread Johan Henriksson
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 interf

Re: [Long] UEFI support

2012-01-06 Thread Ben Hutchings
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 al

Re: [Long] UEFI support

2012-01-06 Thread Philipp Kern
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 pr

[Long] UEFI support

2012-01-06 Thread Tanguy Ortolo
-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 f