1 |
On 06/19/2012 08:22 PM, Rich Freeman wrote: |
2 |
> On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ryao@g.o> wrote: |
3 |
>> I know that the Core Boot project also tries to accomplish this, but |
4 |
their development process is slow and their approach seems to make the |
5 |
boot process more complicated than it needs to be. Since Secure Boot |
6 |
will force us to flash our BIOS chips (or stick to old hardware), I |
7 |
think it would be worthwhile to develop our own solution by extending |
8 |
genkernel. This should have the benefit of making our systems boot faster. |
9 |
> |
10 |
> So, replacing a BIOS is a fairly tall order - I'm not convinced that |
11 |
> Core Boot is slow simply because they're doing it wrong. They're also |
12 |
> looking to add value (like booting a diskless server off of a random |
13 |
> website or whatever - not just simple disk/PXE like most BIOS). My |
14 |
> understanding is that clusters are one of their big use cases. |
15 |
|
16 |
Core Boot is a Linux distribution. I do not think that we should boot |
17 |
Gentoo using their distribution any more than we boot Gentoo using RHEL. |
18 |
|
19 |
> I also don't get the claim that we need to flash our BIOS chips to get |
20 |
> around secure boot. If you don't want to use secure boot just disable |
21 |
> it - it is no harder than changing your boot device order, system |
22 |
> time, or any of a myriad of other firmware settings. It gets more |
23 |
> complicated if you want to keep secure boot but boot your own OS, |
24 |
> since you have to manage the keys/signing/etc. |
25 |
|
26 |
In theory, the kernel could be modified to only execute signed binaries |
27 |
and portage could be modified to produce signed binaries. The user could |
28 |
build a system that required everything to be signed with the private |
29 |
key of his choice. A hardened system that required signed binaries would |
30 |
be even more secure than a typical system using Secure Boot where only |
31 |
the bootloader, kernel and kernel modules are signed. The user would be |
32 |
in full control of his hardware. The user would not need to pay for this |
33 |
and the system would also boot faster. |
34 |
|
35 |
> Nothing is keeping anybody from creating their own firmware. However, |
36 |
> I doubt we'll see 25 devs take this on as a full-time job, which is |
37 |
> probably what it would take to support the bazillions of boards out |
38 |
> there. Keep in mind that many motherboard vendors require signed |
39 |
> firmware so you'll need to find an exploit for every make/model out |
40 |
> there to even load your firmware. That seems a bit much compared to |
41 |
> just disabling secure boot... |
42 |
|
43 |
The 80386's RESET state is emulated uniformly across all x86 and amd64, |
44 |
so it should not take much effort to support the basic functions of |
45 |
setting up the CPU, loading the kernel (from the EEPROM) and jumping |
46 |
into it. Everything else is secondary. |
47 |
|
48 |
Those are the only things that a BIOS replacement needs to do. As you |
49 |
pointed out, Core Boot is trying to add value. That means that they are |
50 |
doing far more than those basic functions. Other features are nice, but |
51 |
not if they get in the way of being able to boot. Other things can come |
52 |
the system boot process works. |
53 |
|
54 |
Basic functionality would only require the work of a few people. Things |
55 |
beyond that (e.g. pre-kernel VGA console initialization, pre-kernel |
56 |
networking, etcetera) might require vendor support through |
57 |
documentation. I would be thrilled if 25 developers wanted to work on |
58 |
this full time, but I am not certain that would make sense. Linux |
59 |
already has thousands of developers working on hardware support, |
60 |
including developers from Intel. We should be able to leverage that. |
61 |
|
62 |
Did I miss any technical obstacles? |