vboot_reference originally used 2-space indentation, rather than
kernel-style tabs. This makes it painful to maintain given that newer
source files are kernel-style.
Re-indent the files that need it, and reflow comments.
No functionality changes.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I7dabed41f69434b1988a52600c0cb1eac8c8d7e6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396488
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Bit 2 in the GPT partition attributes has been allocated as the legacy
bios boot (equivalent to the "active" or "boot" flag in MBR). If we
try to boot images on newer x86 systems, syslinux dies because it can't
find any GPT partition marked bootable.
Update the various parts of cgpt add & show to manage this bit. Now we
can run:
cgpt add -i 12 -B 1 chromiumos_image.bin
And the EFI partition will be marked bootable.
BUG=chromium:644845
TEST=vboot_reference unittests pass
TEST=booted an amd64-generic disk image via USB on a generic laptop
BRANCH=None
Change-Id: I78e17b8df5b0c61e9e2d8a3c703e6d5ad230fe92
Reviewed-on: https://chromium-review.googlesource.com/382411
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Now that we have support for the IGNOREME signature in cgpt, we need a
way to set it on an existing disk. The easiest option is to shoehorn
this into the cgpt legacy command, because that's already made to modify
GPT header signatures (really, it would be nice to rename it to cgpt
signature or something, but let's not break existing uses for now).
BRANCH=None
BUG=chrome-os-partner:52595
TEST=unit tests
Change-Id: If2835fec28a9c39373abd050e2e057f73e5ec700
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340073
Reviewed-by: Nam Nguyen <namnguyen@google.com>
The code to read/write vbnv with mosys was implemented in the
ARM specific code so move it to the generic crosystem code
so it can be used on x86.
No functional changes in this commit.
BUG=chrome-os-partner:51846
BRANCH=none
TEST=emerge-chell vboot_reference; emerge-oak vboot_reference
Change-Id: I3fe18fadb924094e710427208976328caf12a009
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336310
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
postinst needs access to a kernel that is bootable from legacy BIOS.
futility provides extraction of a bootable vmlinuz from the kernel
partition via the command line. This patch provides a function which
does the same thing and is suitable for static linking into postinst
with minimal additonal code linked in. This way we can avoid issues with
running dynamic executables during postinst.
BRANCH=none
TEST=None
BUG=chromium:455343
Change-Id: Iaec2f48e4d8f78a4bbfcc1636b6ce478e95e9a8e
Reviewed-on: https://chromium-review.googlesource.com/251760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
When working on NAND, we do not actually work with one device name. We
work on a temporary file instead. Moreover, depending on the type of the
partition, we need to show different devices.
BUG=None
BRANCH=None
TEST=All commands must be run on storm_nand
TEST=/usr/bin/cgpt.bin find -t kernel should print out /dev/mtd2
TEST=/usr/bin/cgpt.bin find -t rootfs should print out /dev/ubiblock5_0
TEST=/usr/bin/cgpt.bin find -t data should print out /dev/ubi1_0
Change-Id: Ia36777ffa6a9cfc7c8ec4b128e49ece140428238
Reviewed-on: https://chromium-review.googlesource.com/242291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
Previously, "cgpt" called out to "flashrom" directly to read and write
NOR area. This CL removes that dependency and always treats "drive_path"
as the storage of GPT structs. This makes it consistent that whatever
device that cgpt reads from or writes to is always the device that
stores GPT structs. We only need to pass in the size of the drive that
contains the partitions, but we do not need to access to that drive.
More information is in the bug.
BUG=chromium:432611
BRANCH=none
TEST=unittest
CQ-DEPEND=CL:228942
Change-Id: Id0139adf70463cec4f2924de8b9a4725dbec822b
Reviewed-on: https://chromium-review.googlesource.com/229736
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
This CL accesses the partition entry array through its header's
entries_lba value.
Previously, we assume the primary entry array lies on third sector, and
the secondary array lies (1 + 32) sectors from disk end. This assumption
was fine, even Wikipedia assumed the same.
But in order for us to support writing boot code to the third sector (as
required by some Freescale board), the primary entry array must be moved
to another location. Therefore, we must use "entries_lba" to locate the
arrays from now on.
BRANCH=none
BUG=chromium:406432
TEST=unittest
TEST=`cgpt create -p` and then `cgpt show`. Make sure the table
header and entries are properly moved.
Change-Id: Ia9008b0bb204f290b1f6240df562ce7d3a9bbff2
Reviewed-on: https://chromium-review.googlesource.com/213861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
This adds a VB_MAX_STRING_PROPERTY for callers that don't
want to guess at how big to make their buffers.
Additionally, it changes the size parameter to VbGetPropertyString()
from int to size_t.
BUG=None
TEST=compile the code
BRANCH=none
Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5
Reviewed-on: https://chromium-review.googlesource.com/175039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
In several places the existing code assumes LBA, but was improperly converted
to use byte offsets, so multiply by the sector size to correct it and maintain
the same interface between MTD & GPT.
Also, since we will need to cgpt create on /dev/fts, which isn't a stat()able
device, allow providing the disk size on the commandline.
BRANCH=none
BUG=chromium:221745
TEST=make runtests; cgpt create -s 12345 on MTD image
Change-Id: Icc89a4505aba9a3dfc39b176a372f6e12d106aed
Reviewed-on: https://gerrit.chromium.org/gerrit/62675
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
- Refactor cgpt_prioitize.c to completely remove gpt-specific code.
- Refactor cgpt_add.c to isolate gpt-dependence to one helper function
and the backup/restore logic
- Change several common apis to take a struct drive* rather than a GptData*,
this provides a path to cleanly implement mtd versions
BUG=chromium:221745
TEST=no functional changes, existing tests cover this
BRANCH=none
Change-Id: I27ed166aae390aa5dc83062f62939e45122edc76
Original-Change-Id: I1b0a73509efbf22411c4ae5cf044feede0a49a33
Reviewed-on: https://gerrit.chromium.org/gerrit/46548
Tested-by: Albert Chaulk <achaulk@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49788
This is more reliable than reading them through FDT/ACPI, since it reflects
the positions as shown to verified boot code.
Notes:
1. This affects ALL platforms with virtual dev switches (x86 AND arm)
2. The fix should have no effect on older platforms, but I haven't tested those.
BUG=chrome-os-partner:11805
TEST=manual
1. boot in normal mode.
devsw_boot = 0 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
2. boot in developer mode.
localhost ~ # crossystem
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
3. boot in developer-recovery mode using keyboard combo.
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 2 # Recovery mode reason for current boot
recoverysw_boot = 1 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
4. disable WP and reboot. wpsw_boot should be 0.
Change-Id: If4156b5e14c6923c5b331c7e5feaabbffe1dad37
Reviewed-on: https://gerrit.chromium.org/gerrit/29199
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We need to be able to tell when a ChromeOS machine was brought up
using netboot. This condition will be communicated from firmware using
the BINF.3 ACPI object (upcoming u-boot change).
BUG=chrome-os-partner:7952
TEST=manual
. boot a ChromeOS machine using the updated firmware and examine the
main firmware type reported by crossystem:
localhost ~ # echo $(/var/crossystem mainfw_type)
netboot
Change-Id: I35b10f41eb1f928a122c384d0179c9027f263acd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/20707
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Header file changes for wrapper API implementation
Crossystem support for reading recovery reason from VbSharedData, and
explicit support for version 1 VbSharedData structs.
BUG=chromium-os:16970
TEST=make && make runtests; run crossystem on Alex and make sure it still reports recovery_reason in recovery mode.
Change-Id: I15195b899583e425d3c9e8df09842d764528e2cb
Reviewed-on: http://gerrit.chromium.org/gerrit/3203
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This CL builds upon earlier firmware and kernel changes (see CLs
related to the same bug, chromium-os:12522).
ARM firmware now simulates both Nvram storage and VDAT buffer, the
structures the x86 version uses extensively to communicate back and
forth between firmware/kernel/userland.
So, to make crossystem work on arm, all what's needed is to provide
architecture specific interface to Nvram and VDAT simulation, and
architecture specific processing for variables which are accessed on
ARM platforms in a different way.
The few discrepancies and platform specifics which had to be addressed
for ARM specifically are as follows:
- the Nvram contents are cached in the shared memory and available for
reading as part of /sys/kernel/debug/chromeos_arm. When writing
Nvram, the same file needs to be written, but only the 16 bytes
(representing the Nvram contents) are aacepted.
- the VDAT buffer also comes from the shared memory (as part of the
same sysfs file)
- when crossystem starts, it needs to read in this shared memory
contents, a` weak' function VbArchInit() is being added such that it
is provided on ARM platforms only, on x86 an empty stub is called.
- current developer/recovery request/ro firmware switch states are
retrieved through GPIO drivers. The GPIO numbers are defined in the
file, the GPIO driver is supposed to be configured before
crsossystem can operate.
- the BINF values are supplied through an array within shared memory,
it would be easy to refactor both x86 and ARM use the same code to
process BINF values, but with this submission the code is duplicated
to minimize x86 impact.
- the following crossystem variables do not have ARM equivalents,
thier values are reported as '(error)':
recoverysw_ec_boot
savedmem_base
savedmem_size
BUG=chromium-os:12522
TEST=manual:
. bring up a kaen system
. execute the following script to enable the appropriate GPIOSs:
for gpio in 56 59 168; do echo $gpio > /sys/class/gpio/export; done
. run `crossystem' and observe reasonable output values
. to verify that it reads GPIOs properly, try
echo $(./crossystem recoverysw_cur)
with the miniservo 'GOOG_REC' button pressed and released, observe
different readings (note that the state of the button is reversed,
the released button is reported as '1')
. to verify the write capabilities, note that the nvram contents can
be accessed using the following shell commands
echo 3 > /proc/sys/vm/drop_caches
2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && \
od -t x1 /tmp/blk | head -1
(the first command cause the device cache dropped, and the second
command accesses the device contents.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
localhost var # echo $(./crossystem fwb_tries)
10
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 0a 00 be 00 00 00 00 00 00 00 02 00 00 00 a2
localhost var # ./crossystem fwb_tries=9
localhost var # echo $(./crossystem fwb_tries)
9
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 09 00 be 00 00 00 00 00 00 00 02 00 00 00 8a
localhost var #
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Change-Id: Ie4c6ff44441d98a42b1057953208fdb90c08f46d
Reviewed-on: http://gerrit.chromium.org/gerrit/113
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
This should be ready for the ARM team to pick up and work on. I added
a placeholder ARM implementation file, though it's not hooked up in
the Makefile yet.
As soon as you implement the VbNvStorage APIs, all the related
crossystem commands will start working. Ditto for VbSharedData.
The params which x86 gets from ACPI you'll need to get from u-boot
somehow, probably via your own kernel driver.
R=robotboy@chromium.org
BUG=chromium-os:12522
TEST=emerge-x86-alex vboot_reference, make sure it still works on x86
Review URL: http://codereview.chromium.org/6780008
Change-Id: I628ee56508421b937ed50db7cb9b8385408d2f5e
Works for getting switch positions, hwid, fwid.
BUG=chrome-os-partner:1940
TEST=ran manually on Mario and Alex
Review URL: http://codereview.chromium.org/6413002
Change-Id: I874df3b5adf872fec2d36e574cb4b8b4a72d331c
This allows signing using a .pem file using an external program.
It is assumed that the external program reads input from stdin, and outputs signed data on stdout. It takes one argument - the file name for the .pem private key reference. See external_rsa_signer.sh for an example external program.
Example usage:
vbutil_keyblock --pack 4096.keyblock \
--datapubkey 4096.vbpubk \
--signprivate_pem 4096.pem \
--pem_algorithm 8 \
--externalsigner "external_rsa_signer.sh"
I have tried to make the change such that it doesn't impact existing tools/interfaces (since these are used at various places). That said, I am aware of the places where we could just extend an old interface an avoid code duplication but thought I'd put that re-factoring in as a TODO for now. Let me know if you disagree and I can merge them (and changing the existing interface).
BUG=7576
TEST=Extended run_vbutil_tests.sh to test vbutil_keyblock packing using an external signer.
To test, make && make runtests (or just run tests/gen_test_keys.sh; tests/run_vbutils_tests.sh)
Review URL: http://codereview.chromium.org/4194003
Change-Id: I7cc52c8293c04ef9ba074794d046c9a4f19f6bdd
This adds some tools to help us figure out why a particular kernel isn't
booting. Often we suspect it's because it was signed with the wrong keys, or
has flags restricting its use to certain boot modes. This change adds some
tools to extract and display all the keys from the BIOS, and try them on the
various kernels. We also display the sha1sum of all the keys we find, to
make comparing them easier.
Change-Id: I38e447bf95cb6c3a0b87aa949611bb135f2f94b4
BUG=chromeos-partner:888
TEST=manual
To test, obtain a root shell, and run dev_debug_vboot. You should see lots
of useful information go by.
Review URL: http://codereview.chromium.org/3303018
Also, make algorithm unsigned int in most places.
BUG=chrome-os-partner:701
TEST=existing RSA verification tests still pass
Review URL: http://codereview.chromium.org/3136017
This makes it much simpler to keep track of what we're doing.
vbutil_key can now wrap both .keyb and .pem keys. It figures out which is
which by trying both and just using the one that works.
vbutil_keyblock and vbutil_kernel now use .vbprivk files for signing.
replace debug() with VBDEBUG(()) in host-side sources, too.
rename PrivateKeyRead to PrivateKeyReadPem
Add real PrivateKeyRead and PrivateKeyWrite for .vbprivk files.
Review URL: http://codereview.chromium.org/2871033
The --repack option lets us sign a previously signed kernel blob with a new
kernel data key.
The --headeronly option is so we can emit the new verification header
separately from the kernel blob.
More work to come...
Review URL: http://codereview.chromium.org/2812034
This is a mostly NOOP change which modifies the source code
to compile cleanly in the MSVC command line build
environment.
A new makefile is introduced (msc/nmakefile) along with a
README.txt in the same directory explaining how to build
the code in the DOS window. As of this submission the build
is running in a 32 bit environment, the intention is to use
the same makefile for 64 bit builds in the future.
Enabling high compilation warnings level allowed to
identify a couple of bugs in the code which are being fixed.
Not all sources are being compiled in the MSVC environment,
only those in firmware/ and most of those in test/
subdirectories. The benchmark calculations require porting
of the timer facilities and are being postponed.
TEST
Built in DOS and linux environments. Ran unit tests in
linux environment.
Review URL: http://codereview.chromium.org/2809037
Firmware-side code for LoadKernel() is in place now. LoadFirmware() replacement coming soon.
The new functions are implemented in parallel to the existing ones (i.e., everything that used to work still does).
Review URL: http://codereview.chromium.org/2745007
