info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-dev] Killing UEFI Secure Boot
628 views
Skip to first unread message
Richard Yao
Jun 19, 2012, 6:20:02 PM6/19/12
to
I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. With that in mind, I believe we can solve the Secure Boot problem by installing Gentoo on PC hardware like how OpenWRT is installed on routers.
http://wiki.openwrt.org/doc/techref/flash.layout
We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs.
We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development:
http://css.csail.mit.edu/6.858/2011/readings/i386.pdf
Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible:
http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/
http://www.sivava.com/EPROM_Programmer_5.html
Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this:
http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html
I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster.
This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system.
Does anyone have any thoughts, comments or suggestions?
http://wiki.openwrt.org/doc/techref/flash.layout
We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs.
We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development:
http://css.csail.mit.edu/6.858/2011/readings/i386.pdf
Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible:
http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/
http://www.sivava.com/EPROM_Programmer_5.html
Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this:
http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html
I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster.
This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system.
Does anyone have any thoughts, comments or suggestions?
Rich Freeman
Jun 19, 2012, 8:30:02 PM6/19/12
to
On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ry...@gentoo.org> wrote:
> I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster.
So, replacing a BIOS is a fairly tall order - I'm not convinced that
> I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster.
Core Boot is slow simply because they're doing it wrong. They're also
looking to add value (like booting a diskless server off of a random
website or whatever - not just simple disk/PXE like most BIOS). My
understanding is that clusters are one of their big use cases.
I also don't get the claim that we need to flash our BIOS chips to get
around secure boot. If you don't want to use secure boot just disable
it - it is no harder than changing your boot device order, system
time, or any of a myriad of other firmware settings. It gets more
complicated if you want to keep secure boot but boot your own OS,
since you have to manage the keys/signing/etc.
Nothing is keeping anybody from creating their own firmware. However,
I doubt we'll see 25 devs take this on as a full-time job, which is
probably what it would take to support the bazillions of boards out
there. Keep in mind that many motherboard vendors require signed
firmware so you'll need to find an exploit for every make/model out
there to even load your firmware. That seems a bit much compared to
just disabling secure boot...
Rich
Richard Yao
Jun 19, 2012, 9:20:01 PM6/19/12
to
On 06/19/2012 08:22 PM, Rich Freeman wrote:
> On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ry...@gentoo.org> wrote:
>> I know that the Core Boot project also tries to accomplish this, but
their development process is slow and their approach seems to make the
boot process more complicated than it needs to be. Since Secure Boot
will force us to flash our BIOS chips (or stick to old hardware), I
think it would be worthwhile to develop our own solution by extending
genkernel. This should have the benefit of making our systems boot faster.
>
> So, replacing a BIOS is a fairly tall order - I'm not convinced that
> Core Boot is slow simply because they're doing it wrong. They're also
> looking to add value (like booting a diskless server off of a random
> website or whatever - not just simple disk/PXE like most BIOS). My
> understanding is that clusters are one of their big use cases.
Core Boot is a Linux distribution. I do not think that we should boot
> On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ry...@gentoo.org> wrote:
>> I know that the Core Boot project also tries to accomplish this, but
their development process is slow and their approach seems to make the
boot process more complicated than it needs to be. Since Secure Boot
will force us to flash our BIOS chips (or stick to old hardware), I
think it would be worthwhile to develop our own solution by extending
genkernel. This should have the benefit of making our systems boot faster.
>
> So, replacing a BIOS is a fairly tall order - I'm not convinced that
> Core Boot is slow simply because they're doing it wrong. They're also
> looking to add value (like booting a diskless server off of a random
> website or whatever - not just simple disk/PXE like most BIOS). My
> understanding is that clusters are one of their big use cases.
Gentoo using their distribution any more than we boot Gentoo using RHEL.
> I also don't get the claim that we need to flash our BIOS chips to get
> around secure boot. If you don't want to use secure boot just disable
> it - it is no harder than changing your boot device order, system
> time, or any of a myriad of other firmware settings. It gets more
> complicated if you want to keep secure boot but boot your own OS,
> since you have to manage the keys/signing/etc.
and portage could be modified to produce signed binaries. The user could
build a system that required everything to be signed with the private
key of his choice. A hardened system that required signed binaries would
be even more secure than a typical system using Secure Boot where only
the bootloader, kernel and kernel modules are signed. The user would be
in full control of his hardware. The user would not need to pay for this
and the system would also boot faster.
> Nothing is keeping anybody from creating their own firmware. However,
> I doubt we'll see 25 devs take this on as a full-time job, which is
> probably what it would take to support the bazillions of boards out
> there. Keep in mind that many motherboard vendors require signed
> firmware so you'll need to find an exploit for every make/model out
> there to even load your firmware. That seems a bit much compared to
> just disabling secure boot...
so it should not take much effort to support the basic functions of
setting up the CPU, loading the kernel (from the EEPROM) and jumping
into it. Everything else is secondary.
Those are the only things that a BIOS replacement needs to do. As you
pointed out, Core Boot is trying to add value. That means that they are
doing far more than those basic functions. Other features are nice, but
not if they get in the way of being able to boot. Other things can come
the system boot process works.
Basic functionality would only require the work of a few people. Things
beyond that (e.g. pre-kernel VGA console initialization, pre-kernel
networking, etcetera) might require vendor support through
documentation. I would be thrilled if 25 developers wanted to work on
this full time, but I am not certain that would make sense. Linux
already has thousands of developers working on hardware support,
including developers from Intel. We should be able to leverage that.
Did I miss any technical obstacles?
Rich Freeman
Jun 19, 2012, 9:30:01 PM6/19/12
to
On Tue, Jun 19, 2012 at 9:10 PM, Richard Yao <ry...@gentoo.org> wrote:
> On 06/19/2012 08:22 PM, Rich Freeman wrote:
> Core Boot is a Linux distribution. I do not think that we should boot
> Gentoo using their distribution any more than we boot Gentoo using RHEL.
Well, maybe it is a distro in the sense that genkernel or dracut are
> On 06/19/2012 08:22 PM, Rich Freeman wrote:
> Core Boot is a Linux distribution. I do not think that we should boot
> Gentoo using their distribution any more than we boot Gentoo using RHEL.
distros (they bundle a bunch of tools in conjunction with a kernel to
do something). The whole point of Core Boot is to be a BIOS
replacement - either to do work on its own, or to boot something else.
Like UEFI it aims to do more than just load one sector off the hard
drive, check for a magic number, and jump into it.
> In theory, the kernel could be modified to only execute signed binaries
> and portage could be modified to produce signed binaries. The user could
> build a system that required everything to be signed with the private
> key of his choice. A hardened system that required signed binaries would
> be even more secure than a typical system using Secure Boot where only
> the bootloader, kernel and kernel modules are signed. The user would be
> in full control of his hardware. The user would not need to pay for this
> and the system would also boot faster.
computer already. Why replace it?
> The 80386's RESET state is emulated uniformly across all x86 and amd64,
> so it should not take much effort to support the basic functions of
> setting up the CPU, loading the kernel (from the EEPROM) and jumping
> into it. Everything else is secondary.
the BIOS for much of anything. I'm not sure that is absolutely
nothing, but obviously the Core Boot folks have it working in some
cases.
>
> Those are the only things that a BIOS replacement needs to do. As you
> pointed out, Core Boot is trying to add value. That means that they are
> doing far more than those basic functions. Other features are nice, but
> not if they get in the way of being able to boot. Other things can come
> the system boot process works.
>
> Did I miss any technical obstacles?
Honestly, I'd probably ask one of the Core Boot folks. Has anybody
already tried to make a core boot light? If their system already
works on any board out there, then we're re-inventing the wheel. If
theirs doesn't, then we need to ask why, since we're likely to run
into the same barriers.
In any case, this seems like a solution to a problem that we don't
have. Any win7-certified motherboard is doing to be able to boot
without secure boot just fine, so why do we need to replace it with a
minimal firmware that does the same thing? I can see why one might
want to improve on it, with Core Boot and such. However, I suspect
the last thing we want in the Gentoo handbook is for every newbie to
be flashing a Gentoo-made firmware onto their board and we get to deal
with the bricks.
Rich
Richard Yao
Jun 19, 2012, 9:40:02 PM6/19/12
to
On 06/19/2012 09:25 PM, Rich Freeman wrote:
>> In theory, the kernel could be modified to only execute signed binaries
>> and portage could be modified to produce signed binaries. The user could
>> build a system that required everything to be signed with the private
>> key of his choice. A hardened system that required signed binaries would
>> be even more secure than a typical system using Secure Boot where only
>> the bootloader, kernel and kernel modules are signed. The user would be
>> in full control of his hardware. The user would not need to pay for this
>> and the system would also boot faster.
>
> You can do all of this with the UEFI firmware that will come with your
> computer already. Why replace it?
We would gain a faster boot process. We would also enable people to
>> In theory, the kernel could be modified to only execute signed binaries
>> and portage could be modified to produce signed binaries. The user could
>> build a system that required everything to be signed with the private
>> key of his choice. A hardened system that required signed binaries would
>> be even more secure than a typical system using Secure Boot where only
>> the bootloader, kernel and kernel modules are signed. The user would be
>> in full control of his hardware. The user would not need to pay for this
>> and the system would also boot faster.
>
> You can do all of this with the UEFI firmware that will come with your
> computer already. Why replace it?
avoid paying money for keys that can be revoked without a refund.
I would rather people make donations to the Gentoo Foundation
voluntarily than to Verisign out of necessity, but that is just me.
Rich Freeman
Jun 19, 2012, 10:00:02 PM6/19/12
to
On Tue, Jun 19, 2012 at 9:33 PM, Richard Yao <ry...@gentoo.org> wrote:
> On 06/19/2012 09:25 PM, Rich Freeman wrote:
> We would gain a faster boot process. We would also enable people to
> avoid paying money for keys that can be revoked without a refund.
>
While I have no doubt that a determined team could make a firmware
> On 06/19/2012 09:25 PM, Rich Freeman wrote:
> We would gain a faster boot process. We would also enable people to
> avoid paying money for keys that can be revoked without a refund.
>
that booted marginally faster, I don't get the bit about not paying
for keys.
You don't have to pay anybody for a key to boot with UEFI - you just
need to either disable secure boot, or install your own keys. I can't
see how installing your own keys is going to be harder than flashing
the entire BIOS, and if you still want secure boot presumably you
still have to install your own keys.
If somebody wants to make a generic UEFI bootloader for PCs they
should by all means do so - I'm sure people would find use for it. I
just don't see it as an essential ingredient for Gentoo. If I really
wanted to mess with my BIOS I'd probably be loading core boot on it.
Rich
Peter Stuge
Jun 19, 2012, 11:30:02 PM6/19/12
to
Hi, I have about 11 years of experience with coreboot. I got
involved while developing a custom BIOS for an embedded system.
You may already have caught some presentation I or one of the other
developers have made about the project. There's a bunch of links
over at http://www.coreboot.org/Screenshots
Richard Yao wrote:
> Core Boot is a Linux distribution.
Sorry sir, but no.
coreboot (one word, lowercase) is an open source BIOS replacement.
Proprietary BIOSes do two things:
1. hardware initialization
on http://stuge.se/pc2010.png everything red requires init by firmware
2. starts an operating system
this means implementing the BIOS Boot Specification, running
master boot record code into real mode segment 7c00h, eltorito
CD-ROM extensions and all of that crap
coreboot does step 1. and nothign else, and significantly faster than
common proprietary BIOSes.
When coreboot is done it starts another, separate, program, we call
that program "the payload."
The payload and coreboot are stored together in the boot flash, but
are not linked together. The payload can be any bare-metal program.
There are many legacy-free bootloader payloads, including GRUB2 and
gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an
operating system kernel or an embedded application if no OS is
needed. Boot flash are often 32Mbit today, so Linux and a small
initramfs fits comfortably.
The default payload is SeaBIOS, which is also the firmware QEMU uses.
SeaBIOS is an open source legacy BIOS implementation, and the
combination of coreboot and SeaBIOS provides a legacy-compatible
boot environment that starts your system exactly like an
old-fashioned proprietary BIOS.
With coreboot my laptop boots from power button to firefox in a
little over 8 seconds. Out of that time, coreboot runs for about
600 milliseconds. This is a fairly typical number.
> The 80386's RESET state is emulated uniformly across all x86 and amd64,
> so it should not take much effort to support the basic functions of
> setting up the CPU, loading the kernel (from the EEPROM) and jumping
> into it.
This is word for word what the founders of the coreboot project (then
called LinuxBIOS) thought back in 1999, and it blew up in their face.
In the following 15 years hardware has gotten significantly more
complex, and significantly more closed, again please have a look
at http://stuge.se/pc2010.png
The closer you are to the CPU the more impossible it is to acquire
reliable documentation for how to program the hardware.
> Those are the only things that a BIOS replacement needs to do.
Please join the project! If you find lowlevel programming interesting
it is an amazing good time, even if progress is slow at times. Now is
a fantastic time to get involved! For the first time in the history
of the project, there is code in the repository for all current
hardware platforms from both AMD and Intel.
> they are doing far more than those basic functions
I hope I've been able to clarify that actually coreboot does nothing
other than what is neccessary. This is the very essence of coreboot.
> Basic functionality would only require the work of a few people.
I'm afraid that this is rather naive.
An experienced coreboot developer given all required documentation[1]
(and ideally some 100-1000k EUR/USD worth of test equipment) can
possibly do a port to a new hardware platform (new CPU and chipset)
in twelve to eighteen months full time.
A hard core developer but without previous experience from PC
firmware and coreboot should add some six months for loading the
domain into her head.
[1] For Intel this requires two stages of NDAs and a decent business
case where Intel will sell five-six figure amounts of chips, or fewer
chips but to an important customer.
In contrast, AMD put the documentation on their webpage.
NVIDIA did not give the documentation to anyone no matter what the
business case. VIA doesn't publish documentation on the web, but
some coreboot developers do have good relations with them.
Over the last couple years Google have hired most of the active
coreboot developers including the project founder, and they've been
working on support for Intel's Sandy Bridge and Ivy Bridge platforms,
which powers the new Chromebook. I do not know how much time they've
spent, but from my outside view I estimate that it took this amazing
team of engineers between 25 and 30 man-months. This may be a very
optimistic estimate.
These new Intel platforms require a blob, firmware for a
microcontroller in the chipset, which runs while the main CPU is
still held in reset, in order to do some early prepararation of the
system.
The firmware blob is signed by Intel. I don't know if the signature
scheme has been broken, I guess it might at some point, but that will
likely be by the usual IT security crowd suspects.
In Google's coreboot code they are using Intel's reference code for
initializing the memory controller. This is so far also a blob, again
as opposed to AMD who have released their reference code under dual
BSD and GPL license, and although it is theoretically possible to
replace this with self-written code that is not really economical.
Please look through the SDRAM, DDR and DDR2 self-written init code
in coreboot for the various platforms, and then think about the
complexity added by DDR3, and I expect that hardware vendors and
JEDEC are hard at work on DDR4.
Memory controller init involves among other things a brute force
search of electrical signal drive strengths to find the correct
setting for stable operation.
> Linux already has thousands of developers working on hardware support,
> including developers from Intel. We should be able to leverage that.
Forget about that. Everything that happens on the Linux level is
really a different matter.
> Did I miss any technical obstacles?
PCs have 35 years of hardware legacy. It's quite possibly the worst
pile of hardware crap on top of hardware crap you can imagine. It's
a feat that anything works at all.
You mention 80386, but all PCs still start in real mode, 8086 style.
In another five or ten years maybe that will change, and (some)
hardware will become much more locked down. But I'm not sure, DOS
remains a significant market.
Someone said "Intel make the best x86 emulators." and that is spot
on. Besides that microcontroller inside your CPU there's of course
also the CPU microcode. There are no modern x86 machines.
FSF has long considered coreboot a high priority project, because it
makes UEFI irrelevant, and it very much puts users in full control,
while at the same time being transparent thanks to the open source.
They don't do much in terms of contributions though. I can understand
that. The way for coreboot to become relevant is to ship from factory.
Everyone with experience from the IBV (Independent BIOS Vendor)
industry knows what a special marketplace this is. It's very
interesting, but don't let anyone tell you that anything is easy.
The technical obstacles are the least of the problems.
//Peter
involved while developing a custom BIOS for an embedded system.
You may already have caught some presentation I or one of the other
developers have made about the project. There's a bunch of links
over at http://www.coreboot.org/Screenshots
Richard Yao wrote:
> Core Boot is a Linux distribution.
coreboot (one word, lowercase) is an open source BIOS replacement.
Proprietary BIOSes do two things:
1. hardware initialization
on http://stuge.se/pc2010.png everything red requires init by firmware
2. starts an operating system
this means implementing the BIOS Boot Specification, running
master boot record code into real mode segment 7c00h, eltorito
CD-ROM extensions and all of that crap
coreboot does step 1. and nothign else, and significantly faster than
common proprietary BIOSes.
When coreboot is done it starts another, separate, program, we call
that program "the payload."
The payload and coreboot are stored together in the boot flash, but
are not linked together. The payload can be any bare-metal program.
There are many legacy-free bootloader payloads, including GRUB2 and
gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an
operating system kernel or an embedded application if no OS is
needed. Boot flash are often 32Mbit today, so Linux and a small
initramfs fits comfortably.
The default payload is SeaBIOS, which is also the firmware QEMU uses.
SeaBIOS is an open source legacy BIOS implementation, and the
combination of coreboot and SeaBIOS provides a legacy-compatible
boot environment that starts your system exactly like an
old-fashioned proprietary BIOS.
With coreboot my laptop boots from power button to firefox in a
little over 8 seconds. Out of that time, coreboot runs for about
600 milliseconds. This is a fairly typical number.
> The 80386's RESET state is emulated uniformly across all x86 and amd64,
> so it should not take much effort to support the basic functions of
> setting up the CPU, loading the kernel (from the EEPROM) and jumping
> into it.
called LinuxBIOS) thought back in 1999, and it blew up in their face.
In the following 15 years hardware has gotten significantly more
complex, and significantly more closed, again please have a look
at http://stuge.se/pc2010.png
The closer you are to the CPU the more impossible it is to acquire
reliable documentation for how to program the hardware.
> Those are the only things that a BIOS replacement needs to do.
it is an amazing good time, even if progress is slow at times. Now is
a fantastic time to get involved! For the first time in the history
of the project, there is code in the repository for all current
hardware platforms from both AMD and Intel.
> they are doing far more than those basic functions
other than what is neccessary. This is the very essence of coreboot.
> Basic functionality would only require the work of a few people.
An experienced coreboot developer given all required documentation[1]
(and ideally some 100-1000k EUR/USD worth of test equipment) can
possibly do a port to a new hardware platform (new CPU and chipset)
in twelve to eighteen months full time.
A hard core developer but without previous experience from PC
firmware and coreboot should add some six months for loading the
domain into her head.
[1] For Intel this requires two stages of NDAs and a decent business
case where Intel will sell five-six figure amounts of chips, or fewer
chips but to an important customer.
In contrast, AMD put the documentation on their webpage.
NVIDIA did not give the documentation to anyone no matter what the
business case. VIA doesn't publish documentation on the web, but
some coreboot developers do have good relations with them.
Over the last couple years Google have hired most of the active
coreboot developers including the project founder, and they've been
working on support for Intel's Sandy Bridge and Ivy Bridge platforms,
which powers the new Chromebook. I do not know how much time they've
spent, but from my outside view I estimate that it took this amazing
team of engineers between 25 and 30 man-months. This may be a very
optimistic estimate.
These new Intel platforms require a blob, firmware for a
microcontroller in the chipset, which runs while the main CPU is
still held in reset, in order to do some early prepararation of the
system.
The firmware blob is signed by Intel. I don't know if the signature
scheme has been broken, I guess it might at some point, but that will
likely be by the usual IT security crowd suspects.
In Google's coreboot code they are using Intel's reference code for
initializing the memory controller. This is so far also a blob, again
as opposed to AMD who have released their reference code under dual
BSD and GPL license, and although it is theoretically possible to
replace this with self-written code that is not really economical.
Please look through the SDRAM, DDR and DDR2 self-written init code
in coreboot for the various platforms, and then think about the
complexity added by DDR3, and I expect that hardware vendors and
JEDEC are hard at work on DDR4.
Memory controller init involves among other things a brute force
search of electrical signal drive strengths to find the correct
setting for stable operation.
> Linux already has thousands of developers working on hardware support,
> including developers from Intel. We should be able to leverage that.
really a different matter.
> Did I miss any technical obstacles?
pile of hardware crap on top of hardware crap you can imagine. It's
a feat that anything works at all.
You mention 80386, but all PCs still start in real mode, 8086 style.
In another five or ten years maybe that will change, and (some)
hardware will become much more locked down. But I'm not sure, DOS
remains a significant market.
Someone said "Intel make the best x86 emulators." and that is spot
on. Besides that microcontroller inside your CPU there's of course
also the CPU microcode. There are no modern x86 machines.
FSF has long considered coreboot a high priority project, because it
makes UEFI irrelevant, and it very much puts users in full control,
while at the same time being transparent thanks to the open source.
They don't do much in terms of contributions though. I can understand
that. The way for coreboot to become relevant is to ship from factory.
Everyone with experience from the IBV (Independent BIOS Vendor)
industry knows what a special marketplace this is. It's very
interesting, but don't let anyone tell you that anything is easy.
The technical obstacles are the least of the problems.
//Peter
Greg KH
Jun 20, 2012, 4:20:02 PM6/20/12
to
On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> I know that there is a great deal of discussion on the effect that
> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> implemented in the UEFI firmware and if we replace the firmware,
> Secure Boot issues disappear.
Stop right there. That's just not going to happen, sorry. You aren't
> I know that there is a great deal of discussion on the effect that
> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> implemented in the UEFI firmware and if we replace the firmware,
> Secure Boot issues disappear.
going to be able to get a user to replace their BIOS, nor should you
ever want to. You are not going to be able to keep up with the
hundreds, if not thousands, of different motherboards being introduced
every month, in order to just get rid of the secure boot option.
You have a much better chance of just telling the user, "Disable the
Secure Boot option in your BIOS". "No, that doesn't mean that Linux
isn't secure." "Yes, I understand it looks that way."
And the conversation degenerates from there.
Sorry, not a valid solution.
And I want secure boot on my machines, with a key I trust, don't you?
If not, why not? I know lots of others that also want this, why deny
them the ability to run Gentoo on their hardware?
greg k-h
Richard Yao
Jun 20, 2012, 4:20:02 PM6/20/12
to
On 06/20/2012 04:08 PM, Greg KH wrote:
> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>> I know that there is a great deal of discussion on the effect that
>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
>> implemented in the UEFI firmware and if we replace the firmware,
>> Secure Boot issues disappear.
>
> Stop right there. That's just not going to happen, sorry. You aren't
> going to be able to get a user to replace their BIOS, nor should you
> ever want to. You are not going to be able to keep up with the
> hundreds, if not thousands, of different motherboards being introduced
> every month, in order to just get rid of the secure boot option.
OpenWRT does that with routers and Cyanogenmod does that with phones. It
> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>> I know that there is a great deal of discussion on the effect that
>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
>> implemented in the UEFI firmware and if we replace the firmware,
>> Secure Boot issues disappear.
>
> Stop right there. That's just not going to happen, sorry. You aren't
> going to be able to get a user to replace their BIOS, nor should you
> ever want to. You are not going to be able to keep up with the
> hundreds, if not thousands, of different motherboards being introduced
> every month, in order to just get rid of the secure boot option.
seems reason for us to offer it as an option to users. With that said,
this probably won't happen. One of the Core Boot developers informed me
of what is involved in setting up the address space and it is infeasible
for us to do.
> And I want secure boot on my machines, with a key I trust, don't you?
> If not, why not? I know lots of others that also want this, why deny
> them the ability to run Gentoo on their hardware?
was talking about giving them options.
Greg KH
Jun 20, 2012, 4:30:02 PM6/20/12
to
On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> On 06/20/2012 04:08 PM, Greg KH wrote:
> > On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >> I know that there is a great deal of discussion on the effect that
> >> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> >> implemented in the UEFI firmware and if we replace the firmware,
> >> Secure Boot issues disappear.
> >
> > Stop right there. That's just not going to happen, sorry. You aren't
> > going to be able to get a user to replace their BIOS, nor should you
> > ever want to. You are not going to be able to keep up with the
> > hundreds, if not thousands, of different motherboards being introduced
> > every month, in order to just get rid of the secure boot option.
>
> OpenWRT does that with routers and Cyanogenmod does that with phones.
No, neither of them replaces the BIOS in their machines with an
> On 06/20/2012 04:08 PM, Greg KH wrote:
> > On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >> I know that there is a great deal of discussion on the effect that
> >> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> >> implemented in the UEFI firmware and if we replace the firmware,
> >> Secure Boot issues disappear.
> >
> > Stop right there. That's just not going to happen, sorry. You aren't
> > going to be able to get a user to replace their BIOS, nor should you
> > ever want to. You are not going to be able to keep up with the
> > hundreds, if not thousands, of different motherboards being introduced
> > every month, in order to just get rid of the secure boot option.
>
> OpenWRT does that with routers and Cyanogenmod does that with phones.
opensource version. There is no BIOS in those platforms, it's just
uboot or fastboot, the PC-like ecosystem is so vastly different it's
laughable.
> It seems reason for us to offer it as an option to users. With that
> said, this probably won't happen. One of the Core Boot developers
> informed me of what is involved in setting up the address space and it
> is infeasible for us to do.
Don't get "replace all of userspace and the kernel" confused with
"replace the UEFI bios". You do realize that the UEFI bios is at least
double the size of the Linux kernel, with custom device drivers and tons
of other stuff in there? Good luck replacing that...
> > And I want secure boot on my machines, with a key I trust, don't you?
> > If not, why not? I know lots of others that also want this, why deny
> > them the ability to run Gentoo on their hardware?
>
> To be clear, I was not talking about taking away options from users. I
> was talking about giving them options.
away an option to me :)
Anyway, it's all a moot point, as has been explained already, sorry.
greg k-h
Richard Yao
Jun 20, 2012, 4:40:02 PM6/20/12
to
On 06/20/2012 04:20 PM, Greg KH wrote:
> On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
>> On 06/20/2012 04:08 PM, Greg KH wrote:
>>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>>>> I know that there is a great deal of discussion on the effect that
>>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
>>>> implemented in the UEFI firmware and if we replace the firmware,
>>>> Secure Boot issues disappear.
>>>
>>> Stop right there. That's just not going to happen, sorry. You aren't
>>> going to be able to get a user to replace their BIOS, nor should you
>>> ever want to. You are not going to be able to keep up with the
>>> hundreds, if not thousands, of different motherboards being introduced
>>> every month, in order to just get rid of the secure boot option.
>>
>> OpenWRT does that with routers and Cyanogenmod does that with phones.
>
> No, neither of them replaces the BIOS in their machines with an
> opensource version. There is no BIOS in those platforms, it's just
> uboot or fastboot, the PC-like ecosystem is so vastly different it's
> laughable.
The BIOS on our machines is analogous to the flash on those machines on
> On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
>> On 06/20/2012 04:08 PM, Greg KH wrote:
>>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>>>> I know that there is a great deal of discussion on the effect that
>>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
>>>> implemented in the UEFI firmware and if we replace the firmware,
>>>> Secure Boot issues disappear.
>>>
>>> Stop right there. That's just not going to happen, sorry. You aren't
>>> going to be able to get a user to replace their BIOS, nor should you
>>> ever want to. You are not going to be able to keep up with the
>>> hundreds, if not thousands, of different motherboards being introduced
>>> every month, in order to just get rid of the secure boot option.
>>
>> OpenWRT does that with routers and Cyanogenmod does that with phones.
>
> No, neither of them replaces the BIOS in their machines with an
> opensource version. There is no BIOS in those platforms, it's just
> uboot or fastboot, the PC-like ecosystem is so vastly different it's
> laughable.
which the firmware operates. There is no difference.
>> It seems reason for us to offer it as an option to users. With that
>> said, this probably won't happen. One of the Core Boot developers
>> informed me of what is involved in setting up the address space and it
>> is infeasible for us to do.
>
> And I agree with that developer.
>
> Don't get "replace all of userspace and the kernel" confused with
> "replace the UEFI bios". You do realize that the UEFI bios is at least
> double the size of the Linux kernel, with custom device drivers and tons
> of other stuff in there? Good luck replacing that...
Things like being able to boot Windows is unnecessary functionality that
can be removed. The only thing replacement firmware must do is get the
kernel loaded into memory, initialize the structures that the kernel
wants and jump into it. That is it.
>>> And I want secure boot on my machines, with a key I trust, don't you?
>>> If not, why not? I know lots of others that also want this, why deny
>>> them the ability to run Gentoo on their hardware?
>>
>> To be clear, I was not talking about taking away options from users. I
>> was talking about giving them options.
>
> You are taking secure boot out of their systems, that sounds like taking
> away an option to me :)
hard drives. If I replaced its BIOS with our own firmware, I could fix
that. If I had our own firmware and I wanted to do my own key signing, I
could implement that.
If were to replace UEFI with our own firmware, the user would have full
view of the source code, rather than some mystery blob. The pool of
people who could do bug fixes would increase and that in general would
be a good thing.
Technical hurdles will likely prevent this unless we an get vendors to
release documentation. Is there any chance you could contact people at
Intel requesting programming documentation on their memory controller
and anything else we would need to write a small OS that we could flash
in place of UEFI?
Greg KH
Jun 20, 2012, 5:20:02 PM6/20/12
to
On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote:
> On 06/20/2012 04:20 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> >> On 06/20/2012 04:08 PM, Greg KH wrote:
> >>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >>>> I know that there is a great deal of discussion on the effect that
> >>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> >>>> implemented in the UEFI firmware and if we replace the firmware,
> >>>> Secure Boot issues disappear.
> >>>
> >>> Stop right there. That's just not going to happen, sorry. You aren't
> >>> going to be able to get a user to replace their BIOS, nor should you
> >>> ever want to. You are not going to be able to keep up with the
> >>> hundreds, if not thousands, of different motherboards being introduced
> >>> every month, in order to just get rid of the secure boot option.
> >>
> >> OpenWRT does that with routers and Cyanogenmod does that with phones.
> >
> > No, neither of them replaces the BIOS in their machines with an
> > opensource version. There is no BIOS in those platforms, it's just
> > uboot or fastboot, the PC-like ecosystem is so vastly different it's
> > laughable.
>
> The BIOS on our machines is analogous to the flash on those machines on
> which the firmware operates. There is no difference.
There is a huge difference here, please do a bit of research before
> On 06/20/2012 04:20 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> >> On 06/20/2012 04:08 PM, Greg KH wrote:
> >>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >>>> I know that there is a great deal of discussion on the effect that
> >>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> >>>> implemented in the UEFI firmware and if we replace the firmware,
> >>>> Secure Boot issues disappear.
> >>>
> >>> Stop right there. That's just not going to happen, sorry. You aren't
> >>> going to be able to get a user to replace their BIOS, nor should you
> >>> ever want to. You are not going to be able to keep up with the
> >>> hundreds, if not thousands, of different motherboards being introduced
> >>> every month, in order to just get rid of the secure boot option.
> >>
> >> OpenWRT does that with routers and Cyanogenmod does that with phones.
> >
> > No, neither of them replaces the BIOS in their machines with an
> > opensource version. There is no BIOS in those platforms, it's just
> > uboot or fastboot, the PC-like ecosystem is so vastly different it's
> > laughable.
>
> The BIOS on our machines is analogous to the flash on those machines on
> which the firmware operates. There is no difference.
claiming otherwise.
> >> It seems reason for us to offer it as an option to users. With that
> >> said, this probably won't happen. One of the Core Boot developers
> >> informed me of what is involved in setting up the address space and it
> >> is infeasible for us to do.
> >
> > And I agree with that developer.
> >
> > Don't get "replace all of userspace and the kernel" confused with
> > "replace the UEFI bios". You do realize that the UEFI bios is at least
> > double the size of the Linux kernel, with custom device drivers and tons
> > of other stuff in there? Good luck replacing that...
>
> Replacing UEFI does not mean that we need a compatible replacement.
> Things like being able to boot Windows is unnecessary functionality that
> can be removed. The only thing replacement firmware must do is get the
> kernel loaded into memory, initialize the structures that the kernel
> wants and jump into it. That is it.
examples of what needs to happen to get a x86-like machine up and
running to the point at which it is possible to hand off control to a
bootloader.
> >>> And I want secure boot on my machines, with a key I trust, don't you?
> >>> If not, why not? I know lots of others that also want this, why deny
> >>> them the ability to run Gentoo on their hardware?
> >>
> >> To be clear, I was not talking about taking away options from users. I
> >> was talking about giving them options.
> >
> > You are taking secure boot out of their systems, that sounds like taking
> > away an option to me :)
>
> I have an Asus motherboard that fails to boot when it has more than 6
> hard drives. If I replaced its BIOS with our own firmware, I could fix
> that. If I had our own firmware and I wanted to do my own key signing, I
> could implement that.
>
> If were to replace UEFI with our own firmware, the user would have full
> view of the source code, rather than some mystery blob. The pool of
> people who could do bug fixes would increase and that in general would
> be a good thing.
That's not the hard part here, the response from the coreboot developer
should have given you a glimpse into the real difficulties involved.
> Technical hurdles will likely prevent this unless we an get vendors to
> release documentation. Is there any chance you could contact people at
> Intel requesting programming documentation on their memory controller
> and anything else we would need to write a small OS that we could flash
> in place of UEFI?
"anything else" is not trivial.
But feel free to prove me wrong, I love it when that happens :)
greg k-h
Richard Yao
Jun 20, 2012, 6:00:02 PM6/20/12
to
On 06/20/2012 05:09 PM, Greg KH wrote:
>> Technical hurdles will likely prevent this unless we an get vendors to
>> release documentation. Is there any chance you could contact people at
>> Intel requesting programming documentation on their memory controller
>> and anything else we would need to write a small OS that we could flash
>> in place of UEFI?
>
>> Technical hurdles will likely prevent this unless we an get vendors to
>> release documentation. Is there any chance you could contact people at
>> Intel requesting programming documentation on their memory controller
>> and anything else we would need to write a small OS that we could flash
>> in place of UEFI?
>
> Again, see the response from Peter about what is needed here. That
> "anything else" is not trivial.
>
> But feel free to prove me wrong, I love it when that happens :)
>
> greg k-h
>
You must not have read this, where I said that I realized that this is
> "anything else" is not trivial.
>
> But feel free to prove me wrong, I love it when that happens :)
>
> greg k-h
>
infeasible:
On 06/20/2012 04:13 PM, Richard Yao wrote:
>> Stop right there. That's just not going to happen, sorry. You aren't
>> going to be able to get a user to replace their BIOS, nor should you
>> ever want to. You are not going to be able to keep up with the
>> hundreds, if not thousands, of different motherboards being introduced
>> every month, in order to just get rid of the secure boot option.
>
> seems reason for us to offer it as an option to users. With that said,
> this probably won't happen. One of the Core Boot developers informed me
> of what is involved in setting up the address space and it is infeasible
> for us to do.
From what I can tell, the Core Boot developers could use that
> this probably won't happen. One of the Core Boot developers informed me
> of what is involved in setting up the address space and it is infeasible
> for us to do.
documentation. You yourself said "If there's anything that anyone is
thinking I should be doing but seem not to be, please let me know.". Do
you have any intention of acting on that?
Richard Yao
Jun 20, 2012, 6:20:01 PM6/20/12
to
Peter, thanks for the detailed email. I have a few questions.
1. As far as I know, Das U-Boot and Core Boot are mutually exclusive.
Why should Linux distribution developers want to use Core Boot instead
of Das U-Boot?
2. It seems to me that you do not need any Linux code. Exactly what is
the relationship between the Core Boot codebase and the Linux codebase?
3. How does getting a x86 system to boot differ from getting a MIPS
system or ARM system to boot? Does it only work because the vendors made
it work or is x86 fundamentally harder?
On 06/19/2012 11:27 PM, Peter Stuge wrote:
> Hi, I have about 11 years of experience with coreboot. I got
> involved while developing a custom BIOS for an embedded system.
>
> You may already have caught some presentation I or one of the other
> developers have made about the project. There's a bunch of links
> over at http://www.coreboot.org/Screenshots
>
>
> Richard Yao wrote:
1. As far as I know, Das U-Boot and Core Boot are mutually exclusive.
Why should Linux distribution developers want to use Core Boot instead
of Das U-Boot?
2. It seems to me that you do not need any Linux code. Exactly what is
the relationship between the Core Boot codebase and the Linux codebase?
3. How does getting a x86 system to boot differ from getting a MIPS
system or ARM system to boot? Does it only work because the vendors made
it work or is x86 fundamentally harder?
On 06/19/2012 11:27 PM, Peter Stuge wrote:
> Hi, I have about 11 years of experience with coreboot. I got
> involved while developing a custom BIOS for an embedded system.
>
> You may already have caught some presentation I or one of the other
> developers have made about the project. There's a bunch of links
> over at http://www.coreboot.org/Screenshots
>
>
> Richard Yao wrote:
>> Core Boot is a Linux distribution.
>> The 80386's RESET state is emulated uniformly across all x86 and amd64,
>> so it should not take much effort to support the basic functions of
>> setting up the CPU, loading the kernel (from the EEPROM) and jumping
>> into it.
>> so it should not take much effort to support the basic functions of
>> setting up the CPU, loading the kernel (from the EEPROM) and jumping
>> into it.
> This is word for word what the founders of the coreboot project (then
> called LinuxBIOS) thought back in 1999, and it blew up in their face.
>
> In the following 15 years hardware has gotten significantly more
> complex, and significantly more closed, again please have a look
> at http://stuge.se/pc2010.png
>
> The closer you are to the CPU the more impossible it is to acquire
> reliable documentation for how to program the hardware.
>
>
> called LinuxBIOS) thought back in 1999, and it blew up in their face.
>
> In the following 15 years hardware has gotten significantly more
> complex, and significantly more closed, again please have a look
> at http://stuge.se/pc2010.png
>
> The closer you are to the CPU the more impossible it is to acquire
> reliable documentation for how to program the hardware.
>
>
>> Those are the only things that a BIOS replacement needs to do.
> Please join the project! If you find lowlevel programming interesting
> it is an amazing good time, even if progress is slow at times. Now is
> a fantastic time to get involved! For the first time in the history
> of the project, there is code in the repository for all current
> hardware platforms from both AMD and Intel.
>
>
>> they are doing far more than those basic functions
> I hope I've been able to clarify that actually coreboot does nothing
> other than what is neccessary. This is the very essence of coreboot.
>
>
> it is an amazing good time, even if progress is slow at times. Now is
> a fantastic time to get involved! For the first time in the history
> of the project, there is code in the repository for all current
> hardware platforms from both AMD and Intel.
>
>
>> they are doing far more than those basic functions
> I hope I've been able to clarify that actually coreboot does nothing
> other than what is neccessary. This is the very essence of coreboot.
>
>
>> Basic functionality would only require the work of a few people.
>> Linux already has thousands of developers working on hardware support,
>> including developers from Intel. We should be able to leverage that.
>> including developers from Intel. We should be able to leverage that.
> Forget about that. Everything that happens on the Linux level is
> really a different matter.
>
>
> really a different matter.
>
>
>> Did I miss any technical obstacles?
Greg KH
Jun 20, 2012, 6:30:01 PM6/20/12
to
On Wed, Jun 20, 2012 at 05:56:28PM -0400, Richard Yao wrote:
> On 06/20/2012 04:13 PM, Richard Yao wrote:
> >> Stop right there. That's just not going to happen, sorry. You aren't
> >> going to be able to get a user to replace their BIOS, nor should you
> >> ever want to. You are not going to be able to keep up with the
> >> hundreds, if not thousands, of different motherboards being introduced
> >> every month, in order to just get rid of the secure boot option.
> >
> > OpenWRT does that with routers and Cyanogenmod does that with phones. It
> > seems reason for us to offer it as an option to users. With that said,
> > this probably won't happen. One of the Core Boot developers informed me
> > of what is involved in setting up the address space and it is infeasible
> > for us to do.
>
> From what I can tell, the Core Boot developers could use that
> documentation. You yourself said "If there's anything that anyone is
> thinking I should be doing but seem not to be, please let me know.". Do
> you have any intention of acting on that?a
> On 06/20/2012 04:13 PM, Richard Yao wrote:
> >> Stop right there. That's just not going to happen, sorry. You aren't
> >> going to be able to get a user to replace their BIOS, nor should you
> >> ever want to. You are not going to be able to keep up with the
> >> hundreds, if not thousands, of different motherboards being introduced
> >> every month, in order to just get rid of the secure boot option.
> >
> > OpenWRT does that with routers and Cyanogenmod does that with phones. It
> > seems reason for us to offer it as an option to users. With that said,
> > this probably won't happen. One of the Core Boot developers informed me
> > of what is involved in setting up the address space and it is infeasible
> > for us to do.
>
> From what I can tell, the Core Boot developers could use that
> documentation. You yourself said "If there's anything that anyone is
> thinking I should be doing but seem not to be, please let me know.". Do
Getting documentation from Intel without an NDA is not something that it
is possible for me to do, sorry. The coreboot developers have much
better contacts in this area (hint, I have none.)
greg k-h
Duncan
Jun 21, 2012, 4:20:02 AM6/21/12
to
Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted:
> 3. How does getting a x86 system to boot differ from getting a MIPS
> system or ARM system to boot? Does it only work because the vendors made
> it work or is x86 fundamentally harder?
I can answer this one. x86 is harder at the bootloader stage, but in
turn easier, or perhaps simply different, at the kernel and kernel device
interface level.
Consider, most MIPS and ARM systems ship with a specific set of basic
devices, configured to use specific IO addresses, IRQs, etc, and that's
it, at least to get up and running (USB devices, etc, may be able to be
plugged in, but they're not normally needed for boot). If you've been
keeping up with the kernel (say via LWN, etc), this has been one of the
big deals with the ARM tree recently, as until now each "board" had its
own hard-coded kernel config directly in the tree, and it was getting
unmanageable. They're switching to "device tree", etc, allowing the boot
loader to feed the kernel a file with this information at boot time, thus
allowing a whole bunch of different boards to boot off the same shipped
kernel, while at the same time getting the explosion of individual board
files out of the kernel tree. This is a BIG deal on ARM and similar
embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all.
Meanwhile, on x86, the system must be prepared for end-user switch-out of
pretty much everything. memory, storage (consider floppy, hard drive,
optical disk either direct or el-torito, USB stick, etc, all bootable and
all end-user changable!), even quantity and speed of CPUs, and the
firmware BIOS (or replacement) must cope with that and be able to boot
off it. Even back in the 386 era when everything was jumper-configured,
users could still change pretty much everything out, other than the mobo
itself. Now days, it's even MORE complex, as most of these devices can
be configured in dozens or hundreds of mode combinations via "plug-n-
pray", and they often don't /have/ a default -- they **MUST** be so
configured in ordered to be operable for the intended use. Sure, the
BIOS CAN leave some of it for the kernel to do, but other bits, not so
much, as otherwise, how does the kernel even get loaded -- the BIOS must
pick one of the many boot options, configure it (as well as the CPU and
the system between storage and the CPU, storage chipset, memory, etc) at
least well enough to read in the boot loader and/or kernel. None of
that's necessary on ARM, etc, because (pretty much) everything there's a
totally arbitrary-as-shipped config, nothing to dynamically negotiate and
get working before the kernel or secondary bootloader (after the BIOS)
can even work!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
> 3. How does getting a x86 system to boot differ from getting a MIPS
> system or ARM system to boot? Does it only work because the vendors made
> it work or is x86 fundamentally harder?
turn easier, or perhaps simply different, at the kernel and kernel device
interface level.
Consider, most MIPS and ARM systems ship with a specific set of basic
devices, configured to use specific IO addresses, IRQs, etc, and that's
it, at least to get up and running (USB devices, etc, may be able to be
plugged in, but they're not normally needed for boot). If you've been
keeping up with the kernel (say via LWN, etc), this has been one of the
big deals with the ARM tree recently, as until now each "board" had its
own hard-coded kernel config directly in the tree, and it was getting
unmanageable. They're switching to "device tree", etc, allowing the boot
loader to feed the kernel a file with this information at boot time, thus
allowing a whole bunch of different boards to boot off the same shipped
kernel, while at the same time getting the explosion of individual board
files out of the kernel tree. This is a BIG deal on ARM and similar
embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all.
Meanwhile, on x86, the system must be prepared for end-user switch-out of
pretty much everything. memory, storage (consider floppy, hard drive,
optical disk either direct or el-torito, USB stick, etc, all bootable and
all end-user changable!), even quantity and speed of CPUs, and the
firmware BIOS (or replacement) must cope with that and be able to boot
off it. Even back in the 386 era when everything was jumper-configured,
users could still change pretty much everything out, other than the mobo
itself. Now days, it's even MORE complex, as most of these devices can
be configured in dozens or hundreds of mode combinations via "plug-n-
pray", and they often don't /have/ a default -- they **MUST** be so
configured in ordered to be operable for the intended use. Sure, the
BIOS CAN leave some of it for the kernel to do, but other bits, not so
much, as otherwise, how does the kernel even get loaded -- the BIOS must
pick one of the many boot options, configure it (as well as the CPU and
the system between storage and the CPU, storage chipset, memory, etc) at
least well enough to read in the boot loader and/or kernel. None of
that's necessary on ARM, etc, because (pretty much) everything there's a
totally arbitrary-as-shipped config, nothing to dynamically negotiate and
get working before the kernel or secondary bootloader (after the BIOS)
can even work!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Richard Yao
Jun 21, 2012, 5:40:02 AM6/21/12
to
drives, hard drives, optical drives, usb devices, isa devices, pci
devices and pci express drives, etcetera, because those live on buses,
which the kernel can detect. It would need a device tree to inform the
kernel of what buses are available, but that would be specific to a
given board, rather than what is attached to it. If the end user makes
hardware changes, the kernel should be able to handle that, with the
exception of changes involving RAM, which I believe go into the device tree.
With that said, I am not convinced by your argument that x86 is
fundamentally more complex. Many of the things you attributed to the
BIOS are in fact handled by the kernel. There is plenty of duplication
between the two, where the BIOS will configure things and then the
kernel will configure them again. However, the BIOS does not accomplish
anything useful in those cases.
Ian Stakenvicius
Jun 21, 2012, 11:10:02 AM6/21/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I take it the above statement is based on the kernel being directly
placed within the BIOS/firmware/nvram on the board, such that you
couldn't boot anything else but that kernel? Otherwise I don't see
how you could get away with the BIOS not worrying about all those
devices.. IE, I don't forsee many general x86 users giving up their
ability to boot off usb stick or cdrom or pxe based on a boot-time
bios choice, or to boot windows or alternative linux kernels (which
could be located who knows where) at whim. And I don't see how an
alternative BIOS would be able to provide this ability without dealing
with all the things Duncan mentioned...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU
7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI
=CwME
-----END PGP SIGNATURE-----
Hash: SHA256
placed within the BIOS/firmware/nvram on the board, such that you
couldn't boot anything else but that kernel? Otherwise I don't see
how you could get away with the BIOS not worrying about all those
devices.. IE, I don't forsee many general x86 users giving up their
ability to boot off usb stick or cdrom or pxe based on a boot-time
bios choice, or to boot windows or alternative linux kernels (which
could be located who knows where) at whim. And I don't see how an
alternative BIOS would be able to provide this ability without dealing
with all the things Duncan mentioned...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU
7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI
=CwME
-----END PGP SIGNATURE-----
Richard Yao
Jun 21, 2012, 11:10:02 AM6/21/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/21/2012 11:00 AM, Ian Stakenvicius wrote:
>> A firmware replacement for the BIOS does not need to worry about
>> floppy drives, hard drives, optical drives, usb devices, isa
>> devices, pci devices and pci express drives, etcetera, because
>> those live on buses, which the kernel can detect. It would need
>> a device tree to inform the kernel of what buses are available,
>> but that would be specific to a given board, rather than what is
>> attached to it. If the end user makes hardware changes, the
>> kernel should be able to handle that, with the exception of
>> changes involving RAM, which I believe go into the device tree.
>
> I take it the above statement is based on the kernel being
> directly placed within the BIOS/firmware/nvram on the board, such
> that you couldn't boot anything else but that kernel?
That is correct.
> Otherwise I don't see how you could get away with the BIOS not
> worrying about all those devices.. IE, I don't forsee many general
> x86 users giving up their ability to boot off usb stick or cdrom or
> pxe based on a boot-time bios choice, or to boot windows or
> alternative linux kernels (which could be located who knows where)
> at whim. And I don't see how an alternative BIOS would be able to
> provide this ability without dealing with all the things Duncan
> mentioned...
An initramfs should be able to provide all of that functionality.
iQIcBAEBAgAGBQJP4zgzAAoJECDuEZm+6ExkeSUP/0PrjZtnWvbdXpTYwTN/U1wq
lVl/nx6mXAq6wwxrhgHMzMvzh68oxqAhZgOASLFoQnO92WbVJzxBZtxBQftR5TGV
k5NGVKCLwVkIi7tQGLk3vLHo3l6MnmwCjmfSCSbr7VEqil2hgy5EwhUiWvibzKlp
34m9g75Z/JR/dMk7qcG7z2lvJNSDlL2Ufgqi5YPQqqmqsMHGi350ZM91dkilOkV2
OtBwJzD+JlvQl+ALBv33KmI37VslcB/ydcx08YfE6BuOkHdusOM6/Den4JUrmS2I
WDvcejzgxjneOifoL+0hiM9ooG3L6Q19G3ZNSSqAit85P5ms6Cm9Bul2lO6+EiQu
iwYLcH/5nwkVC/8bRaHvzTnSaKyvyip9lKzeZyD9fnsMirxV6R3T3aWyIwhBdb8E
pe85C+n4Wd5n4nhuwQW8AP860yftco9aNSrx1uIb+PMEi38+yLTwNjrR/shQ7RcK
76mpWIWat/YpLRNF9Va7PN3FaslsTGVyQdgcBtci9S9IXWhwGyc7ZDS7DIq7CYTT
9pE9dYqDOmEl0kWt5e4EgrjD4ibwhOsvddBJBcW2spphnRBuHwkzdp7K7pW3KX1z
Wj4triKllBLwMJvIcDk6Nv0tm0YO+kzxDhEsjBajjDR48652ijF6RYLi2cV7Ui+9
Hnsvgz6oEc7sNL9VbPnZ
=Aacv
-----END PGP SIGNATURE-----
Hash: SHA1
On 06/21/2012 11:00 AM, Ian Stakenvicius wrote:
>> A firmware replacement for the BIOS does not need to worry about
>> floppy drives, hard drives, optical drives, usb devices, isa
>> devices, pci devices and pci express drives, etcetera, because
>> those live on buses, which the kernel can detect. It would need
>> a device tree to inform the kernel of what buses are available,
>> but that would be specific to a given board, rather than what is
>> attached to it. If the end user makes hardware changes, the
>> kernel should be able to handle that, with the exception of
>> changes involving RAM, which I believe go into the device tree.
>
> I take it the above statement is based on the kernel being
> directly placed within the BIOS/firmware/nvram on the board, such
> that you couldn't boot anything else but that kernel?
> Otherwise I don't see how you could get away with the BIOS not
> worrying about all those devices.. IE, I don't forsee many general
> x86 users giving up their ability to boot off usb stick or cdrom or
> pxe based on a boot-time bios choice, or to boot windows or
> alternative linux kernels (which could be located who knows where)
> at whim. And I don't see how an alternative BIOS would be able to
> provide this ability without dealing with all the things Duncan
> mentioned...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAEBAgAGBQJP4zgzAAoJECDuEZm+6ExkeSUP/0PrjZtnWvbdXpTYwTN/U1wq
lVl/nx6mXAq6wwxrhgHMzMvzh68oxqAhZgOASLFoQnO92WbVJzxBZtxBQftR5TGV
k5NGVKCLwVkIi7tQGLk3vLHo3l6MnmwCjmfSCSbr7VEqil2hgy5EwhUiWvibzKlp
34m9g75Z/JR/dMk7qcG7z2lvJNSDlL2Ufgqi5YPQqqmqsMHGi350ZM91dkilOkV2
OtBwJzD+JlvQl+ALBv33KmI37VslcB/ydcx08YfE6BuOkHdusOM6/Den4JUrmS2I
WDvcejzgxjneOifoL+0hiM9ooG3L6Q19G3ZNSSqAit85P5ms6Cm9Bul2lO6+EiQu
iwYLcH/5nwkVC/8bRaHvzTnSaKyvyip9lKzeZyD9fnsMirxV6R3T3aWyIwhBdb8E
pe85C+n4Wd5n4nhuwQW8AP860yftco9aNSrx1uIb+PMEi38+yLTwNjrR/shQ7RcK
76mpWIWat/YpLRNF9Va7PN3FaslsTGVyQdgcBtci9S9IXWhwGyc7ZDS7DIq7CYTT
9pE9dYqDOmEl0kWt5e4EgrjD4ibwhOsvddBJBcW2spphnRBuHwkzdp7K7pW3KX1z
Wj4triKllBLwMJvIcDk6Nv0tm0YO+kzxDhEsjBajjDR48652ijF6RYLi2cV7Ui+9
Hnsvgz6oEc7sNL9VbPnZ
=Aacv
-----END PGP SIGNATURE-----
Roy Bamford
Jun 21, 2012, 3:00:02 PM6/21/12
to
On 2012.06.21 16:05, Richard Yao wrote:
> On 06/21/2012 11:00 AM, Ian Stakenvicius wrote:
> >> A firmware replacement for the BIOS does not need to worry about
> >> floppy drives, hard drives, optical drives, usb devices, isa
> >> devices, pci devices and pci express drives, etcetera, because
> >> those live on buses, which the kernel can detect. It would need
> >> a device tree to inform the kernel of what buses are available,
> >> but that would be specific to a given board, rather than what is
> >> attached to it. If the end user makes hardware changes, the
> >> kernel should be able to handle that, with the exception of
> >> changes involving RAM, which I believe go into the device tree.
> >
> > I take it the above statement is based on the kernel being
> > directly placed within the BIOS/firmware/nvram on the board, such
> > that you couldn't boot anything else but that kernel?
>
> That is correct.
>
[snip]
> On 06/21/2012 11:00 AM, Ian Stakenvicius wrote:
> >> A firmware replacement for the BIOS does not need to worry about
> >> floppy drives, hard drives, optical drives, usb devices, isa
> >> devices, pci devices and pci express drives, etcetera, because
> >> those live on buses, which the kernel can detect. It would need
> >> a device tree to inform the kernel of what buses are available,
> >> but that would be specific to a given board, rather than what is
> >> attached to it. If the end user makes hardware changes, the
> >> kernel should be able to handle that, with the exception of
> >> changes involving RAM, which I believe go into the device tree.
> >
> > I take it the above statement is based on the kernel being
> > directly placed within the BIOS/firmware/nvram on the board, such
> > that you couldn't boot anything else but that kernel?
>
> That is correct.
>
So when you build a dud kernel and flash your BIOS with it, and we all
build the odd dud, your motherboard is bricked.
Now what?
Get out your JTAG adaptor and another PC I suppose.
--
Regards,
Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees
Peter Stuge
Jun 21, 2012, 3:20:01 PM6/21/12
to
Roy Bamford wrote:
> > > I take it the above statement is based on the kernel being
> > > directly placed within the BIOS/firmware/nvram on the board,
This is sometimes called Linux-as-bootloader (LAB/lab for short) in
> > > I take it the above statement is based on the kernel being
> > > directly placed within the BIOS/firmware/nvram on the board,
the coreboot project.
> > > such that you couldn't boot anything else but that kernel?
> So when you build a dud kernel and flash your BIOS with it, and we
> all build the odd dud, your motherboard is bricked.
done unless you are comfortable with the modification, or with
solving a brick problem. :)
Keep backup flash chips, if your boot flash is socketed.
There are also several software techniques to eliminate and/or
reduce the brick risk.
Again, if you flash nothing but a kernel into the boot flash then
the machine will just laugh at you in your face and not start.
coreboot has infrastructure for separating normal boot from fallback
boot, for when the normal boot fails.
Writing to the flash chip is not an all-or-nothing operation.
coreboot uses a super simple filesystem for the boot flash, which can
be aligned to eraseblocks in the flash chip, such that only ever the
normal boot "files" are erased and rewritten, while leaving fallback
contents untouched. Even a power outage during flashing will not
brick your machine.
> Get out your JTAG adaptor and another PC I suppose.
the boot flash can always be written with other suitable dedicated
hardware, from "the outside", as you write.
//Peter
Rich Freeman
Jun 21, 2012, 7:00:02 PM6/21/12
to
On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge <pe...@stuge.se> wrote:
> Roy Bamford wrote:
>
>> So when you build a dud kernel and flash your BIOS with it, and we
>> all build the odd dud, your motherboard is bricked.
>
> Any firmware modification has potential to brick, and shouldn't be
> done unless you are comfortable with the modification, or with
> solving a brick problem. :)
So, why are we still going back and forth about this? If people want
> Roy Bamford wrote:
>
>> So when you build a dud kernel and flash your BIOS with it, and we
>> all build the odd dud, your motherboard is bricked.
>
> Any firmware modification has potential to brick, and shouldn't be
> done unless you are comfortable with the modification, or with
> solving a brick problem. :)
to work on coreboot they can do so (I'm sure they have a list). If
people want to fork coreboot or redo it from scrach they can do so and
start their own list.
When it is shiny and perfect and has a following of hundreds of linux
users we can always discuss whether we recommend using it in the
handbook on -dev then. Otherwise it seems about as on-topic as
debating whether grub or systemd or openrc should have feature A/B/C -
we're a DISTRO - we integrate and ship what upstream gives us...
Rich
Richard Yao
Jun 21, 2012, 8:30:01 PM6/21/12
to
On 06/21/2012 06:51 PM, Rich Freeman wrote:
> On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge <pe...@stuge.se> wrote:
>> Roy Bamford wrote:
>>
> On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge <pe...@stuge.se> wrote:
>> Roy Bamford wrote:
>>
>>> So when you build a dud kernel and flash your BIOS with it, and we
>>> all build the odd dud, your motherboard is bricked.
>>
>> Any firmware modification has potential to brick, and shouldn't be
>> done unless you are comfortable with the modification, or with
>> solving a brick problem. :)
>
>>> all build the odd dud, your motherboard is bricked.
>>
>> Any firmware modification has potential to brick, and shouldn't be
>> done unless you are comfortable with the modification, or with
>> solving a brick problem. :)
>
> So, why are we still going back and forth about this?
This idea has technical merit and it has sparked a very insightful
discussion in which I learned many things that I did not know. My
original intention in emailing the list was to learn such things, so my
email has fulfilled its purpose.
My email has also led to an interesting off list conversation between
myself and Peter about this. I believe that the exchange of ideas that
this prompted has been mutually beneficial. My hope is that our
discussion catalyzes improvements in both Gentoo and coreboot.
On 06/21/2012 06:51 PM, Rich Freeman wrote:
> we're a DISTRO - we integrate and ship what upstream gives us...
of upstream programming and is also upstream for some things. Do you
consider it to be inappropriate for us to play a larger role in both
upstream development and as upstream ourselves?
Duncan
Jun 22, 2012, 1:10:01 AM6/22/12
to
Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
> A firmware replacement for the BIOS does not need to worry about floppy
> drives, hard drives, optical drives, usb devices, isa devices, pci
> devices and pci express drives, etcetera, because those live on buses,
> which the kernel can detect.
But you have to be able to load the kernel first, before it can do all
that detection. And to load it, you need to be able to read the device
it's located on, which in a modern x86 system (as contrasted with mips/
arm) generally means detection of what's there, some mechanism to choose
which available devices to check for a kernel or boot loader or whatever,
and some way to dynamically configure it, since many devices are simply
(device info probable) bricks until configured, these days.
Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
S suggested), but then you're back to hard-configuring it in ordered to
do so, thus losing all that extra flexibility that's part of what makes
x86 different. Which was the question that I was addressing.
> A firmware replacement for the BIOS does not need to worry about floppy
> drives, hard drives, optical drives, usb devices, isa devices, pci
> devices and pci express drives, etcetera, because those live on buses,
> which the kernel can detect.
that detection. And to load it, you need to be able to read the device
it's located on, which in a modern x86 system (as contrasted with mips/
arm) generally means detection of what's there, some mechanism to choose
which available devices to check for a kernel or boot loader or whatever,
and some way to dynamically configure it, since many devices are simply
(device info probable) bricks until configured, these days.
Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
S suggested), but then you're back to hard-configuring it in ordered to
do so, thus losing all that extra flexibility that's part of what makes
x86 different. Which was the question that I was addressing.
Richard Yao
Jun 22, 2012, 1:20:01 AM6/22/12
to
On 06/22/2012 01:02 AM, Duncan wrote:
> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
>
>> A firmware replacement for the BIOS does not need to worry about floppy
>> drives, hard drives, optical drives, usb devices, isa devices, pci
>> devices and pci express drives, etcetera, because those live on buses,
>> which the kernel can detect.
>
> But you have to be able to load the kernel first, before it can do all
> that detection. And to load it, you need to be able to read the device
> it's located on, which in a modern x86 system (as contrasted with mips/
> arm) generally means detection of what's there, some mechanism to choose
> which available devices to check for a kernel or boot loader or whatever,
> and some way to dynamically configure it, since many devices are simply
> (device info probable) bricks until configured, these days.
>
> Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
> S suggested), but then you're back to hard-configuring it in ordered to
> do so, thus losing all that extra flexibility that's part of what makes
> x86 different. Which was the question that I was addressing.
>
Placing it in the firmware is what I suggested. I also later stated that
> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
>
>> A firmware replacement for the BIOS does not need to worry about floppy
>> drives, hard drives, optical drives, usb devices, isa devices, pci
>> devices and pci express drives, etcetera, because those live on buses,
>> which the kernel can detect.
>
> But you have to be able to load the kernel first, before it can do all
> that detection. And to load it, you need to be able to read the device
> it's located on, which in a modern x86 system (as contrasted with mips/
> arm) generally means detection of what's there, some mechanism to choose
> which available devices to check for a kernel or boot loader or whatever,
> and some way to dynamically configure it, since many devices are simply
> (device info probable) bricks until configured, these days.
>
> Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
> S suggested), but then you're back to hard-configuring it in ordered to
> do so, thus losing all that extra flexibility that's part of what makes
> x86 different. Which was the question that I was addressing.
>
it is possible for the firmware to contain an initramfs that would
enable it to start a kernel located on a device.
It seems to me that this would work if device trees for motherboards
were readily available and the EEPROM chips have sufficient capacity. I
am under the impression that UEFI firmware is large enough that capacity
on UEFI motherboards should not be an issue. The main issue would be
obtaining device trees.
Richard Yao
Jun 22, 2012, 1:40:03 AM6/22/12
to
controller and possibly a few other bits prior to loading the kernel is
also necessary. I omitted that by mistake.
Ian Stakenvicius
Jun 22, 2012, 9:10:02 AM6/22/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 21/06/12 08:24 PM, Richard Yao wrote:
> On 06/21/2012 06:51 PM, Rich Freeman wrote:
>> we're a DISTRO - we integrate and ship what upstream gives us...
>
> RHEL is a distribution, but I understand that RedHat does a great
> deal of upstream programming and is also upstream for some things.
> Do you consider it to be inappropriate for us to play a larger role
> in both upstream development and as upstream ourselves?
>
As a gentoo developer in general? Absolutely not. Through discussion
on this list specifically? possibly. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/kbQEACgkQ2ugaI38ACPDCrAEAquDX0hrTUufGqXhSG2Cv+yLU
bmw3WpMa17OHSmbZ+3QA/Am2K80tHFGDA7uklTUm6Lxe8wynVRTNrmpD93qTlJ4R
=gO47
-----END PGP SIGNATURE-----
Hash: SHA256
On 21/06/12 08:24 PM, Richard Yao wrote:
> On 06/21/2012 06:51 PM, Rich Freeman wrote:
>> we're a DISTRO - we integrate and ship what upstream gives us...
>
> RHEL is a distribution, but I understand that RedHat does a great
> deal of upstream programming and is also upstream for some things.
> Do you consider it to be inappropriate for us to play a larger role
> in both upstream development and as upstream ourselves?
>
on this list specifically? possibly. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
bmw3WpMa17OHSmbZ+3QA/Am2K80tHFGDA7uklTUm6Lxe8wynVRTNrmpD93qTlJ4R
=gO47
-----END PGP SIGNATURE-----
0 new messages