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.
>> 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.
>>> 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.
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?
06-20-2012, 09:09 PM
Greg KH
Killing UEFI Secure Boot
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
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.
A BIOS does much much more than just that. See the coreboot code for
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.
You do realize that the majority of the UEFI code is opensource, right?
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?
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
06-20-2012, 09:56 PM
Richard Yao
Killing UEFI Secure Boot
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?
>
> 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
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.
>
> 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?
06-20-2012, 10:16 PM
Richard Yao
Killing UEFI Secure Boot
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:
>> 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
>
06-20-2012, 10:27 PM
Greg KH
Killing UEFI Secure Boot
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
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
06-21-2012, 08:08 AM
Duncan
Killing UEFI Secure Boot
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
06-21-2012, 09:33 AM
Richard Yao
Killing UEFI Secure Boot
On 06/21/2012 04:08 AM, Duncan wrote:
> 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!
>
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.
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.
06-21-2012, 03:00 PM
Ian Stakenvicius
Killing UEFI Secure Boot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 21/06/12 05:33 AM, Richard Yao wrote:
> On 06/21/2012 04:08 AM, Duncan wrote:
>> 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!
>>
>
> 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...
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
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]
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
Killing UEFI Secure Boot
