scottk/OpenCellular
1
0
Fork 0
mirror of https://github.com/Telecominfraproject/OpenCellular.git synced 2025-11-25 10:45:02 +00:00
Code Issues Packages Projects Releases Wiki Activity
1,105 Commits 52 Branches 2 Tags
fe2c1a231e3893dc3d7ac314e11b04a18c6948e7
Commit Graph

4 Commits

Author SHA1 Message Date
Kees Cook
e0e4ed404b vbutil_kernel: copy zeropage fully 
When copying the vmlinuz zeropage, the entries were being truncated even
though the boot protocol version was being retained. This means that
booting a kernel that depended on details from the zeropage's ignored
areas would find invalid information. Fix this by copying out the entire
possible range of memory.

BUG=chromium:230212
TEST=kernels can boot with CONFIG_RELOCATABLE
BRANCH=None

Change-Id: Ifb94bedcf881e17ab20fff44d8c1c1885b15ef9e
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47832
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
 2013-04-11 11:29:39 -07:00
Che-Liang Chiou
036922ed8a Read kernel body load address from preamble by default 
The default behavior of dump_kernel_config is changed from using
CROS_32BIT_ENTRY_ADDR to reading from kernel preamble.  The main
motivation for this change is in preparation for ARM boards of which
kernel body load address cannot be CROS_32BIT_ENTRY_ADDR.  Since we do
not want that all ARM calling sides of dump_kernel_config have to carry
the kloadaddr argument, it would be better to let dump_kernel_config
read this address from the kernel preamble by default.

BUG=chromium-os:28077
TEST=Run dump_kernel_config w/ and w/o this change

Change-Id: I5eddcc35e5970dfce02cc66208438c57351f1c81
Reviewed-on: https://gerrit.chromium.org/gerrit/19660
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
 2012-04-06 04:08:54 -07:00
Che-Liang Chiou
475bf447cc Add fake e820 memory map entries to zeropage 
BUG=chromium-os:4521
TEST=manual

This patch set adds two e820 memory map entries to kernel's zeropage to
trick kernel into booting; otherwise kernel will choke on missing e820
memory map.

The added e820 memory map entries should let kernel boot and should not
make the memory map differ from that without the added entries.

Test Procedure:
1. Boot your test machine and save dmesg output, referred to as LOG1.
2. Apply the following one-line patch and then compile and install
   kernel.
3. Apply this patch set and re-build zeropage on kernel partition.
4. Boot the test machine and save dmesg output, referred to as LOG2.

LOG1 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

LOG2 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  BIOS-e820: 00000000fffff000 - 0000000100000000 (reserved)
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

Test result:
1. Compare the first paragraph of excerpts from LOG1 and LOG2:
   This shows that the fake e820 memory map entries are successfully
   added.
2. Compare the second paragraphs of excerpts from LOG1 and LOG2:
   This shows that the added entries do not modify the memory map.

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 49706d0..c9075ee 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -425,7 +425,7 @@ static int __init append_e820_map(struct e820entry
*biosmap, int nr_map)
 {
        /* Only one memory region (or negative)? Ignore it */
        if (nr_map < 2)
-               return no_e820_map_return();
+               return -1;

        return __append_e820_map(biosmap, nr_map);
 }

Review URL: http://codereview.chromium.org/3176019
 2010-08-23 11:20:44 +08:00
Randall Spangler
7d6898dbaa Added vbutil_kernel. 
Review URL: http://codereview.chromium.org/2730011
 2010-06-11 09:22:13 -07:00