The major() func is defined in the sys/sysmacros.h header, so include it
explicitly for the prototype. Upstream C libs are moving away from having
sys/types.h include it all the time implicitly.
BUG=None
TEST=precq passes
BRANCH=None
Change-Id: I56b84138f08ded2376193403f9c9db22c5f24f71
Reviewed-on: https://chromium-review.googlesource.com/339680
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Add a new crossystem value "battery_cutoff_request" to indicate that
next reboot should cut-off battery and shutdown during firmware stage.
This request is primarily for factories to ship devices in an safe
state. Previously we have done same thing by running "ectool battery-cutoff"
but that creates a problem which "ectool" (and the one to request for
cut-off) must live in developer mode while the device must be shipped
in normal mode. The mode transition was solved by setting
"disable_dev_request=1", but that flag is may get lost on x86 systems
(having NV storage in CMOS) when the battery is cut-off .
From the experience from Ryu, such settings (dev mode transition and
battery cut-off) should be done together inside firmware execution so we
can create a new flag, battery_cutoff_request, to finalize device
properly.
BRANCH=none
BUG=chromium:601705
TEST=emerge-chell depthcharge vboot_reference chromeos-bootimage
crossystem battery_cutoff_request=1
# Unplug AC adapter
reboot
# See device rebooted and then shutdown immediately.
# Press power button and system won't boot.
# Attach AC adapter and now system boots.
CQ-DEPEND=CL:337596,CL:338193
Change-Id: I73ccae15b337cd65786106646546c67c155b8fa6
Reviewed-on: https://chromium-review.googlesource.com/337602
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
If this is an x86 system using vboot2 then write VbNv data
to CMOS and also use mosys to write it directly to flash.
BUG=chrome-os-partner:51846
BRANCH=none
TEST=emerge-chell vboot_reference; emerge-oak vboot_reference
verify on chell that "crossystem dev_disable_request=1" is
written to both CMOS and flash.
Change-Id: Ifd5dcee4d401f8de36801c5c0a7db3255e618e28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336311
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
In order to support slots, we need to update behavior of
GptUpdateKernelWithEntry so that:
1. Invalid - Marks kernel entry as invalid
2. Active - Marks kernel entry as active
CQ-DEPEND=CL:336906
BUG=chrome-os-partner:51807
BRANCH=None
TEST=Compiles successfully "sudo emerge vboot_reference" "emerge-smaug
vboot_reference". "make -j runtests" successful.
Change-Id: If248b3c6bdd23d03cb1dd24f4e21cacef5cc3f26
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/335942
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Often the partitions we extract have extra space in them, but the dd
utility will still write out the excess zeros. That can mean we write
out hundreds of megs of data which could otherwise be skipped. We thus
waste a good amount of I/O and storage.
For now, only use this flag when extracting a partition to a new file
as this should be safe (there's no pre-existing data to clobber/merge).
Now that the signers have been upgraded to Trusty, we can land this.
BUG=chromium:530730
TEST=`./signing_unittests.py` passes
BRANCH=None
Change-Id: I275973ebfc028c15a8d1ef33dd9b3dcf6ca726a2
Reviewed-on: https://chromium-review.googlesource.com/306420
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Amey Deshpande <ameyd@google.com>
If a platform does verification of memory init then it must be careful
to use the same slot for resume that it booted from. This is
accomplished by adding a context flag to indicate this is an S3 resume
and that vboot should treat it differently than a normal boot.
When this flag is set then the same slot that was booted is read from
VBNV and re-used for the resume path, without adjusting any try flags.
If this slot is B then the related context flag is set.
This will allow the firmware updater to update the other (non-booted)
slot and set flags indicating that on the next boot the updated slot
should be tried, while still allowing suspend/resume to work with the
existing firmware slot.
This assumes that the last tried slot was successfully booted, which
should be a safe assumption since the system was able to boot and then
suspend. It isn't reliable to check last_fw_result for "success"
status because that status is only set some time after boot when
chromeos-setgoodkernel calls chromeos-firmwareupdate --mode=bootok
and so it may still report a status of "trying" on resume depending
on how soon after boot the suspend happened.
It also avoids setting the vboot flag indicating that a slot choice
was made in order to avoid altering the try counter on failure since
this is explicitly not attempting to boot the new slot.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I500faef2b5d19a02f32839976354abf6d551c9f6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vboot needs to track the currently displayed screen so when it needs to
change the locale or display the debug overlay it knows which screen to
redraw. Currently only the legacy path is doing this so change the new
path to update the current screen if it is successfully drawn.
BUG=chrome-os-partner:49766
BRANCH=glados
TEST=boot on glados in dev mode, hit tab and ensure screen does not go black
Change-Id: I4a2bf028275db57b2d0469fc1cb574e871820713
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/324549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For x86 systems, which resume through the boot reset vector, to
implement vboot verification of the memory init code one needs
check that the slot chosen on the resume path is the same as
the original boot path. That check is done by storing the
resulting hash of the slot. However, vb2api doesn't export
the resulting hash from vb2api_check_hash(). Thus, provide
a variant which saves the resulting digest in the supplied
buffer.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
Change-Id: Ic20be2024afedabc2d8bc767f1b794376348523c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/323460
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The VBOOT_OPROM_NEEDED flag is used for EC software sync when the
VBSD_EC_SLOW_UPDATE flag is set.
After a successful EC software sync vboot requests a reboot to disable
graphics but it is not clearing the VBNV flag first. With vboot1 this
was getting cleared as a side effect of calling VbInit in normal mode.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Enable EC_SLOW_UPDATE on chell and test EC software sync in normal
mode and ensure that it reboots and does not do graphics init if the
update is successful.
Change-Id: I2aa0c4c3b1ad357a5b8ddc14539e264a1f5b76b2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322731
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow the AP to sync and verify the EC read only image after updating
the rewritable image.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=manual
1. Update EC to a new version
2. rebuild EC code
3. Update AP firmware
4. Reboot and check that the RO image is updated after the RW image is
updated.
CQ-DEPEND=CL:319213
Change-Id: I774ef25320103f20d8c7d1c180a220dd0819c04d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Kernel TPM patches from 4.x moved /sys/class/misc/tpm0 to /sys/class/tpm/tpm0.
Support both paths in this utility.
BUG=chromium:573368
BRANCH=none
TEST=untested, not sure if this utility is still used.
Change-Id: Ib81476eee4c9de921502a3a47f6990b9e6b1968b
Reviewed-on: https://chromium-review.googlesource.com/320892
Commit-Ready: Bryan Freed <bfreed@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change will be used to support EC-RO software sync by allowing for
access to the readonly region of firmware. Currently only the writable
section is accessed by vboot using VB_SELECT_FIRMWARE_A and B.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=built on jerry and check that the RO hash can be read and the image
can be updated.
CQ-DEPEND=CL:319185,CL:320425,CL:320598
Change-Id: Ic3942d86b65da3123798cfd11a78056f5dab6699
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319213
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Musl complains about using sys/fcntl.h, and with -Werror that
gives a compilation failure. Every other file includes <fcntl.h>
so just use that.
Change-Id: Ibc743bbe335e9e9b91da7e4eacc01cc80cd8b35a
Reviewed-on: https://chromium-review.googlesource.com/313419
Commit-Ready: Doug Evans <dje@google.com>
Tested-by: Doug Evans <dje@google.com>
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
This flag will be used by the firmware updater to indicate that RO
software sync should be attempted.
BUG=chrome-os-partner:48703
BRANCH=None
TEST=make runtests
Change-Id: I42090ac47da45c724e66334648ab447ad3c21178
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a standalone library for verifying the BDB structures in the
common boot flow document, and a bdb_create utility to create test BDB
structures. Eventually, creating these structures will be rolled into
futility.
BUG=chrome-os-partner:48448
BRANCH=none
TEST=cd bdb && make runtests
Change-Id: Ic57c26ca84137205da3b6c7d532f5324c93b4285
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/317275
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The standalone accessories are using a key name like this:
key_<product>.pem or key_<product>.vbprik2
when it doesn't exist, fallback using key.pem or key.vbprik2.
BRANCH=none
BUG=chrome-os-partner:47557
TEST=manual:
./scripts/image_signing/sign_official_build.sh accessory_usbpd ../ec/build/zinger/ec.bin tests/devkeys-acc /tmp/ec-zinger.TEST.SIGNED.bin
./scripts/image_signing/sign_official_build.sh accessory_rwsig ../ec/private/build/hadoken/keyboard_app.bin tests/devkeys-acc /tmp/ec-hadoken.TEST.SIGNED.bin
./scripts/image_signing/sign_official_build.sh accessory_rwsig ../ec/private/build/hadoken/keyboard_app.bin /tmp /tmp/ec-hadoken.TEST.SIGNED.bin
Change-Id: I68863664bdb9da1695e91b1986f3a0148af7da26
Reviewed-on: https://chromium-review.googlesource.com/312836
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
New devices have Depthcharge render vboot screens by calling
vboot_draw_screen. Thus, display initialization and backlight control should
not be duplicated. This patch prevents VbDisplayScreen from initializing
display and controlling backlight when vboot is rendering screens using GBB.
BUG=chrome-os-partner:43706,chromium:502066
BRANCH=tot
TEST=Tested on Glados
Change-Id: I50cd2decb7065af96779601b12f0fbf2554ff6ed
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312749
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
I don't even know what this is. It seems to have marked some kind of
debug buffer provided by H2C BIOS on pre-Daisy Chromebooks and has not
been touched since it was copied in here when crossystem was first
added. I can't find any references in our codebase so I doubt anybody
would miss it. Let's remove it so the '(error)' fields returned there on
any modern Chromebook stop confusing our vendors.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: Ie2baec536b50bb192eb4cd3e48df212cce53561a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311346
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
This field doesn't seem to be used for anyone and it keeps adding work
for people trying to bring up new platforms. If we ever needed something
like this again, we'd probably prefer to have it in mosys now anyway.
Let's get rid of it.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: I6b96e255968fdd22a345d4a75bfdc1e79d3f5896
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311345
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Move around the test keys used for standalone accessories signing
unittesting, so they are easier to use.
BRANCH=smaug, samus
BUG=chrome-os-partner:46635
TEST=run cros-signing unittests (./signing_unittests.py)
Change-Id: I02fcf444ec76bf6ebf6eb477e1236869aa877210
Reviewed-on: https://chromium-review.googlesource.com/309967
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Add a new post-EC software sync API VbExEcVbootDone() to take actions
which normally need to happen after EC verification / sysjump.
BUG=chromium:537269
TEST=Manual on Glados. Set CHG_MW thresh to 20000, BAT_PCT to 50. Verify
that LIMIT_POWER host event is set until Zinger negotiates to 20V. Also
verify that we do not proceed with boot when Donette is plugged.
BRANCH=None
CQ-DEPEND=CL:307885,CL:309523
Change-Id: I77e6000aa8a44e3aca4fb5982e5b5f5191774989
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307952
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
My previous patch using futility to re-sign standalone accessory
firmware images had a mistake in the key directory path : fix it.
Also add RSA-2048 'accessory' keys for signer unit testing.
BRANCH=smaug, samus
BUG=chrome-os-partner:46635
TEST=run cros-signing unittests (./signing_unittests.py)
Change-Id: Ia2f641c85337c67f81968be4730643a6ad5f22cf
Reviewed-on: https://chromium-review.googlesource.com/309530
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
FASTBOOT_FULL_CAP set
This change allows developers to boot dev-signed boot images in
unlocked mode if DEV_BOOT_FASTBOOT_FULL_CAP is set in VbNvStorage or
GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set.
BUG=chrome-os-partner:47002
BRANCH=None
TEST=Compiles successfully. make -j runtests
Change-Id: I56e3879594da1b57051dfe242ff347ac970c96bb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309606
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use futility to re-sign standalone accessory firmware images either the
former "usbpd1" used by USB Power Delivery firmware generated from the
EC codebase or the new "rwsig" format.
BRANCH=smaug, samus
BUG=chrome-os-partner:46635
TEST=manual:
openssl genrsa -F4 -out key_zinger.pem 2048
openssl genrsa -F4 -out key_hadoken.pem 2048
futility create --desc="Hadoken fake MP key" key_hadoken.pem key_hadoken
./scripts/image_signing/sign_official_build.sh accessory_usbpd build/zinger/ec.bin . build/zinger/ec.SIGNED.bin
./scripts/image_signing/sign_official_build.sh accessory_rwsig build/hadoken/keyboard_app.bin . build/hadoken/keyboard_app.SIGNED.bin
and compare the re-signed files with the original files.
Change-Id: I586ba3e4349929782e734af1590f394824e7dd44
Reviewed-on: https://chromium-review.googlesource.com/306795
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When a user hits esc+refresh+power to start recovery, the true recovery
reason will be lost after reboot. (It would always look like
VB2_RECOVERY_RO_MANUAL.) This patch makes VbBootRecovery save
the reason in the subcode area before entering the new 'broken' loop.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: Ib536daa0633721bfc975381782d348f122b3d337
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
VbExGetLocalizationCount is a callback function which is supposed to
return the number of screen locales supported by VbExDisplayScreen.
After this change, we still try to get the number of locales from GBB
first but when it fails, VbExGetLocalizationCount is called. The error
code from VbGbbReadBmpHeader will be masked, similarly to the error from
VbDislayScreenFromGBB.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests
Change-Id: I04ef8bf1ea02b1aaa05e65673b57bcea1932d8b0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304376
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for PEM file containing a RSA Public key in futility "show"
and "create" commands.
When "futility create" is given a PEM file with only a RSA public key,
generate the proper .vbpubk2 rather than failing.
BRANCH=smaug
BUG=none
TEST=make runtests
and run manually
futility show tests/testkeys/key_rsa4096.pub.pem
futility show tests/testkeys/key_rsa4096.pem
Change-Id: I707ceca54c80ba21f53869ad86c86fa23b31e665
Reviewed-on: https://chromium-review.googlesource.com/306683
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Verify the size of the buffer read from the file before trying to use 1KB of
it for the new rwsig format detection.
Add a new test case with a short file containing only 4 bytes of unknown
data and run "futility show" on it.
BRANCH=smaug
BUG=none
TEST=futility show foobar.pub.pem
where foobar.pub.pem is a 451-byte file.
check that "make runtests" passes with the fix
and fails without it with the following message :
test_file_types.sh ... failed
FAIL: 13 / 14 passed
Change-Id: Ia9d68c6b528c2b3a595ea6791c907374616d051f
Reviewed-on: https://chromium-review.googlesource.com/306682
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The "rwsig" type is used for independent device firmware (not
Chromebook BIOS) that need to verify themselves instead of using
software sync.
The expected use case is that a RO firmware contains a
vb2_public_key struct along with an FMAP or other pointers to a
slot for RW firmware. The RW firmware slot reserves room for a
vb2_signature struct.
This CL changes the args and behavior of the rwsig type, so that
the RW firmware can be [re]signed independently of the rest of
the image.
BUG=chrome-os-partner:46254
BRANCH=smaug,ToT
TEST=make runtests, manual
Create a keypair:
futility create --desc "Key One" tests/testkeys/key_rsa2048.pem foo
Sign a RW binary and build a complete image out of the parts:
futility sign --type rwsig --prikey foo.vbprik2 rw.bin sig.bin
dd if=/dev/zero bs=65536 count=1 of=image.bin
dd if=rw.bin of=image.bin conv=notrunc
dd if=sig.bin bs=$((65536 - 1024)) seek=1 of=image.bin conv=notrunc
Verify both the separate parts and the combined image:
futility show --type rwsig --pubkey foo.vbpubk2 rw.bin sig.bin
futility show --type rwsig --pubkey foo.vbpubk2 image.bin
Re-sign the combined image with a different keypair:
futility create --desc "Key Two" tests/testkeys/key_rsa1024.pem bar
futility sign --type rwsig --prikey bar.vbprik2 image.bin
Now the first key no longer verifies:
futility show --type rwsig --pubkey foo.vbpubk2 image.bin
But the second key does:
futility show --type rwsig --pubkey bar.vbpubk2 image.bin
Change-Id: Ifdddab08f218f506eb1dce28851b153d70140a7b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305980
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This reverts commit 82dec09bd5.
This flag doesn't exist on Ubuntu Precise which is what the signers
are running atm. Until we get them upgraded to Trusty, back this
change out.
BUG=chromium:530730
TEST=`./signing_unittests.py` passes
BRANCH=None
Change-Id: I9ba508c1531dbb169fd020d06ab102f6576b7342
Reviewed-on: https://chromium-review.googlesource.com/306310
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Amey Deshpande <ameyd@google.com>
This change makes VbDisplayScreen read the last saved locale from nvram
and pass it to VbExDisplayScreen so that it can draw locale dependent
screens.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests.
CQ-DEPEND=CL:304382,CL:306100,CL:306110
Change-Id: I9782ec5a8a9f8393998aa8a0d64e88ad1809233b
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304375
This adds the "rwsig" type, with initial support for RO+RW
firmware images that need to verify themselves instead of using
software sync. This uses our vb2 structs instead of raw binary
blobs. That will help us locate, identify, and verify the keys
and signatures in the signed firmware images.
BUG=chrome-os-partner:46254
BRANCH=smaug,ToT
TEST=make runtests
I also hacked up a test board with the EC-side signature
verification routines from a preliminary CL and tested this
signing scheme with that. It works.
Additional work is needed to make this seamless, but you can try
it out like so:
futility create ./tests/testkeys/key_rsa2048.pem foo
futility sign --type rwsig --prikey foo.vbprik2 --pubkey foo.vbpubk2 ec.bin
Change-Id: I876ab312a2b0b36411c5f739fe3252529728d034
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305394
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In developer mode, this option will make the system try to boot into
a legacy OS first after the 30 second timeout. This removes the need to
press a key during boot to try legacy mode and the need to remove the
write protect screw to boot legacy as default.
BUG=chromium:310697
BRANCH=none
TEST=make runtests
Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the new recovery process, a user will see 'broken' screen
instead of 'remove' screen, where usb stick presence is no longer
detected. A user instead has to hit esc+refresh+power to proceed
to recovery mode.
BUG=chromium:501060
BRANCH=tot
TEST=make runtests
Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857
Reviewed-on: https://chromium-review.googlesource.com/304404
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Specifically, this patch updates 'root_hexdigest' in legacy bootloader
templates in EFI system partition to match the signed rootfs.
BRANCH=None
BUG=chromium:512940
TEST=Ran sign_official_build.sh locally and booted the image on kvm
(using BIOS).
TEST=Ran signing_unittests.py by locally changing vboot_stable_hash to
include this patch.
$ ./sign_official_build.sh base chromiumos_base_image.bin \
../../tests/devkeys chromiumos_base_image_signed.bin
Change-Id: Ied021c4464b113a64508f5081605069bdcecbc1f
Reviewed-on: https://chromium-review.googlesource.com/301742
Commit-Ready: Amey Deshpande <ameyd@google.com>
Tested-by: Amey Deshpande <ameyd@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The firmware for the USB Type-C power adapters uses raw binary
blobs for the public keys and signatures instead of
readily-identifiable structs. We've been able to sign these
firmware images for some time, but verifying the result generally
required testing them on hardware.
This CL adds some futilty support for recognizing and verifying
those images too. It just tries various sig and hash algorithms,
until it finds a combination for which the image is
self-consistent (where the pubkey blob verifies the signature
blob).
BUG=none
BRANCH=none
TEST=make runtests
This change also adds additional tests for usbpd1 images. We
ensure that we correctly recognize and verify an MP-signed
firmware, plus test signing and verifying usbpd1 images using
multiple signature and hash algorithms.
Change-Id: I4fbe8b37a694992f635d5469ae1c2449b1610dfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302415
Reviewed-by: Randall Spangler <rspangler@chromium.org>
