| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For test purposes it should be possible to clear the wipeout request
raised by firmware.
BRANCH=none
BUG=chrome-os-partner:36059
TEST=verified that crossystem wipeout_request=0 changes the bit from 1
to 0, and wipeout_request=1 does not change it from 0 to 1.
Change-Id: Ic45ec03ed3e40e6fee4244804b8c231ee88af95b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262466
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commands reads/sets a bit in the kernel-reserved area
of the vboot context nvram. The bit can also be set by the
driver during execution of a TPM command, to check if the
command is interrupted by a panic or power loss. Under
some circumstances, this correlates with the TPM assuming
it is under attack.
BUG=chromium:431360
TEST=try "crossystem tpm_attack" and variations
BRANCH=none
Change-Id: I87215d5a0becfb5c01e0b69867a339bfe6fd0b68
Reviewed-on: https://chromium-review.googlesource.com/261339
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has become necessary to be able to "factory reset" certain devices
on firmware request. The best mechanism for this is NVRAM, as the
request needs to be detected very early in the boot process, before
other means of communications with the upper layers are available.
A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for
this purpose.
A new flag is introduced to allow the firmware to signal the need to
assert this bit.
A new variable name/parameter ('wipeout_request') added to crossystem
to provide user space access to the setting of the dedicated NVRAM
bit.
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259857
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CL:221230 added the new NVRAM fields fw_prev_tried and fw_prev_result.
It also provided support in the crossystem library to decode these
values, but it forgot to add them to the table of allowed crossystem
options so they actually cannot be queried by the command line tool. Fix
that since this information is useful to debug failures after updating.
BRANCH=R41
BUG=chrome-os-partner:36183
TEST=make runtests VBOOT2=1. cros deployed onto Jerry and confirmed
fw_prev_tried and fw_prev_result are correct.
Change-Id: I8bad7266379d959f5370b7ebeefbbba939c5de06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows testing vboot2. These fields are ignored by original
vboot firmware.
BUG=chromium:370082
BRANCH=none
TEST=manual
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A
crossystem fw_tried=B
echo $? -> 1
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A
crossystem fw_try_next=B
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B
crossystem fw_try_next=beats_me
echo $? -> 1
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B
crossystem fw_try_next=A
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A
crossystem fw_result=trying
crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A
crossystem fw_result=bupkis
echo $? -> 1
crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A
crossystem fw_result=success
crossystem -> fw_tried=A, fw_result=success, fw_try_next=A
crossystem fw_result=failure
crossystem -> fw_tried=A, fw_result=failure, fw_try_next=A
crossystem fw_result=unknown
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A
crossystem -> fw_try_count = 0, fwb_tries = 0
crossystem fw_try_count=6
crossystem -> fw_try_count = 6, fwb_tries = 6
crossystem fwb_tries=0
crossystem -> fw_try_count = 0, fwb_tries = 0
Change-Id: I1532f3384f8c05de2a7ff3f35abcc35d18049491
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TEST=Done manually on Nyan:
localhost ~ # sudo /tmp/crossystem fw_vboot2
0
localhost ~ # sudo /tmp/crossystem fw_vboot2=1
localhost ~ # sudo /tmp/crossystem fw_vboot2
0
# reboot with vboot2 firmware
localhost ~ # /tmp/crossystem fw_vboot2
1
BUG=none
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I6ed553c48bdfebf07393f6f5f46832a60971314a
Reviewed-on: https://chromium-review.googlesource.com/205664
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.
If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.
This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:
block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx
Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.
Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.
FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.
BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual
Testing this is a long and involved process. Read on...
First, there are host-side tests for it. In the chroot:
cd src/platform/ec
make runtests
Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:
Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored
Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.
Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh
Reboot in recovery mode, and insert a USB stick with a test image on it.
NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.
Run
make_dev_ssd.sh --remove_rootfs_verification --recovery_key
Reboot (recovery mode)
Run
mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled
Reboot (recovery mode).
Run "tpmc getvf". It should say
deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0
Run "tpmc geto". It should say
Owned: no
Now you'll need to build the "tpm-nvtool" utility. In the chroot:
cd src/third_party/tpm/nvtool
make
Copy that to the DUT, in /usr/local/bin.
Now run
tcsd
tpm-nvtool --list | grep Index
You may see a number of spaces, but you should at least see these:
# NV Index 0x00001007
# NV Index 0x00001008
Run
tpm_takeownership
It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".
Run
tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"
Verify that it worked with
tpm-nvtool --list | grep Index
Power off.
Using servo, flash the new BIOS that has this CL in it.
Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run
tpm-nvtool --list | grep Index
You should now see at least these spaces:
# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009
Now you're ready to test the backup/recover feature.
Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, this does nothing. It just sets a flag that nothing looks at.
Don't get all wound up - we haven't abandoned our principles. This will
eventually be used to allow enterprise-enrolled customers to prevent
unauthorized use of developer mode in the Chrome OS devices that THEY OWN.
This is not Google deciding to turn a feature off, it's allowing the OWNER
to control the use of the feature. In some situations, the owner can be held
liable for what others do with the owner's equipment. This will help the
owner avoid those situations while their device is out of their immediate
control.
BUG=none
BRANCH=ToT
TEST=manual
Set the flag with:
crossystem block_devmode=1
Clear it with:
crossystem block_devmode=0
Retrieve the value ("0" or "1") like so:
val=$(crossystem block_devmode)
echo "the flag is $val"
or just test it directly like so:
if crossystem 'block_devmode?1' ; then
echo "devmode is blocked"
else
echo "devmode is allowed"
fi
It should be persistent across reboots.
Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197771
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Querying "debug_build" allows the caller to determine whether the
image has requested debug, independent of the setting of the
dev_mode switch.
BUG=chromium:308678
BRANCH=none
TEST=use the new command option on both base and dev images
Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda
Reviewed-on: https://chromium-review.googlesource.com/174107
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
|
|
|
BUG=chromium-os:26317
BRANCH=none
TEST=manual
sudo emerge vboot_reference
emerge-link vboot_reference chromeos-u-boot chromeos-installer
emerge-daisy vboot_reference chromeos-u-boot chromeos-installer
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I8c55ca40f3f0cacf08530ab63c886fe351bcee8e
Reviewed-on: https://gerrit.chromium.org/gerrit/41152
|
