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>
This stops creating dump_fmap as a standalone utility and builds it into
futility. Since it was already invoked as a symlink, no user-visible changes
should be observed.
BUG=chromium:224734
BRANCH=none
TEST=manual, trybots
sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-$BOARD vboot_reference
Change-Id: I68d1bea0c1867043b2633e15509b95c2717009a7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47672
Reviewed-by: Randall Spangler <rspangler@chromium.org>
FindKernelConfig() is used to extract the kernel cmdline from a kernel
partition. It's only used in the chromeos-installer, but was a bit awkward.
This changes the calling parameters to make it simpler.
BUG=chromium:221544
BRANCH=none
TEST=manual
CQ-DEPEND=CL:46835
FEATURES=test sudo emerge vboot_reference
FEATURES=test emerge-$BOARD vboot_reference
Change-Id: Ib7192175d72ad51387d8d122ead4490a4aa62300
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46834
The chromeos-installer uses several functions from the vboot_reference
userspace library, but the names of those functions are inconsistent:
IsZero
MapFile
VbGetSystemPropertyString
cgpt_add
cgpt_boot
cgpt_create
cgpt_get_boot_partition_number
cgpt_get_num_non_empty_partitions
cgpt_get_partition_details
cgpt_prioritize
cgpt_set_attributes
find_kernel_config
The Google C++ style guide says types and functions should use CamelCase,
while variables use lower_case_with_underscores.
Kernel style (which vboot_reference tries to be more-or-less compatible
with) uses lower_case_with_underscores for everything, but that really only
has to apply to firmware stuff. For userspace, we can use the Google style.
BUG=chromium:221544
BRANCH=none
TEST=buildbot
CQ-DEPEND=CL:46045
Renaming/cleanup only; no functional changes.
Change-Id: I9c82c9ff8909be88586194c8ffdb435fc771195f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46044
These were macros that were never used, or that were only set to one thing and
could be substituted up front.
I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.
BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None
Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This moves all the old userspace utilities generated by vboot_reference into
a subdirectory not in $PATH, and replaces them with symlinks to a single
executable named 'futility'. At the moment that utility just execs the
original utilities (optionally logging that fact first).
Ultimately, the old utilities will be subsumed into a single binary instead
of multiple separate executables.
There is a matching CL needed to make the recovery image creation work.
BUG=chromium-os:37062
BRANCH=none
CQ-DEPEND=CL:44864
TEST=auto
To test, build everything, test everything. It should work as before in all
cases. I have built normal images, test images, factory installers, recovery
images; they all seem to work.
I've run trybots on daisy-paladin link-paladin lumpy-paladin and alex-paladin.
Change-Id: Ie93db676f2ed2a64e4b13b3b5dc6b65a77db0f8c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This utility sets up the encrypted directories for Chrome OS at boot time.
It uses some of the TPM-related libraries from vboot_reference, but it
isn't really part of the verified boot process itself so I'm moving it into
the cryptohome repo where it belongs.
This CL just removes the code from vboot_reference. Another CL will put it
into cryptohome, and yet another will change the ebuilds to notices.
BUG=chromium-os:39264
BRANCH=none
TEST=auto
CQ-DEPEND=CL:44301, CL:44302
This is just refactoring, not a new feature. After all the CLs are in, the
platform_EncryptedStateful autotest should continue to pass as before.
Change-Id: I6bb436ae57140e89581cb0be5dc2385b8f3ff5e2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44303
Reviewed-by: Kees Cook <keescook@chromium.org>
In an effort to reduce the chances of a kernel bug wrecking filesystems
during encrypted-stateful shutdown, add explicit sync() calls during
shutdown.
BUG=chrome-os-partner:17610
TEST=link build, shutdown with simulated panic in LOOP_CLR_FD results in
successful journal replays
BRANCH=None
Change-Id: I4be981ebd0270d275ae81a79e3195bc72b70d984
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43736
Reviewed-by: Grant Grundler <grundler@chromium.org>
AFAICT, we don't actually run this test anywhere. If we do, we shouldn't
hard-code the path to the real chromeos-tpm-recovery utility, because we
may need to move it around.
BUG=none
BRANCH=none
TEST=none
Change-Id: I295d57d659adf564ca964efc91d95dfdd1ff00aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43174
Reviewed-by: Randall Spangler <rspangler@chromium.org>
EC verification is done via software sync; the EC doesn't do vboot on
its own.
BUG=chromium-os:38139
BRANCH=none
TEST=manual
make runtests
emerge-link vboot_reference chromeos-u-boot chromeos-bootimage
Change-Id: I6e5c0db8fc54b474f044d37c2603a9c116747a85
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41953
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Export the NVRAM contents to tmpfs (/tmp) for use during boot without
incurring the cost of repeated trips through the TPM.
Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:37367
TEST=builds, boots, emits lockbox.nvram which validates using in-progress lockbox-cache
BRANCH=none
Change-Id: I8b1103f4bd22bd75e98a7617a571bdb3a06d2914
Reviewed-on: https://gerrit.chromium.org/gerrit/41433
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Queue: Will Drewry <wad@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
This is immediately needed to debug a Parrot TPM problems, but
we've had similar situation in the past and probably will again
in the future.
BUG=chromium-os:37819
TEST=manually tested with a couple of different packets, and error inputs
BRANCH=none
Change-Id: Id7f66bdbdfe5887fa49cd62af4a9b807fa3d9a89
Reviewed-on: https://gerrit.chromium.org/gerrit/41166
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
If a system key is available (could read TPM NVRAM), but the "finalization
needed" file exists, it means that we are in the situation where either
cryptohome was interrupted, or the TPM was temporarily unavailable at an
earlier boot. In this case, it is up to mount-encrypted to perform the
finalization. Before, we were making the very bad assumption that the
keyfile was valid if a system key was found, meaning we would delete the
"finalization needed" file, leaving us with no way to find the encryption
key leading to an OOBE on the next boot.
BUG=chrome-os-partner:15960
TEST=daisy build, manual testing
BRANCH=None
Change-Id: Ifb6d74d8a38100e00d9a4597c25a71a6c33f806c
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39883
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
This just adds a one-byte field in the nvstorage region for use in debugging
hard-to-catch errors. There's no official meaning or expectation for this
field. It's just a handy place to emit some information.
BUG=chrome-os-partner:11534
BRANCH=parrot
TEST=manual
Just change the value and ensure that it persists across a (working) reboot.
It's only updated at specific points under very exacting error conditions,
so all we really want to test is that it works as a place to store some
extra info.
crossystem recovery_subcode
crossystem recovery_subcode=14
reboot
crossystem recovery_subcode
The recovery_subcode byte is at index [6] of the VbNv.raw bytes that appear
when you press TAB, so you can find it there too:
VbNv.raw: 60 20 00 00 00 00 0e 00 00 00 00 00 00 00 00 65
Decimal 14 == 0x0e
Change-Id: I1930b8f81a03ab838dbee99a8d72c35a444efdfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39803
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Make sure all Tlcl users benefit from the new retry logic.
BUG=None
TEST=daisy build, manual testing of racing tpmc loops
BRANCH=None
Change-Id: I8e9656a65b5d6b45694c1c8bceb95f54f7c751bb
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39525
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Snow was built with overlapping regions in its FMAP, so when we use
dump_fmap -h to see what the layout is, it complains and dies. This change
lets it keep going if you give it multiple -h args. Nothing else is different.
BUG=none
BRANCH=none
TEST=manual
This complains and quits:
dump_fmap -h image-snow.bin
This complains and keeps going:
dump_fmap -hh image-snow.bin
Change-Id: Ia4592b9ba6963b8c5064dd6f51625e9495db2845
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39551
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the TPM hits an error other than ENOENT during open(), retry for 5
seconds with 100ms polling delays. Also switch to on-demand opening
of TPM, so umount will not hit delays if tcsd keeps the TPM open at
shutdown time.
BUG=chrome-os-partner:15960
TEST=daisy build, mount ok with kernel patched to return EBUSY for a few
opens, platform_EncryptedStateful passes.
BRANCH=None
Change-Id: Ia597622bb54ccc4366be2a0c960c518406e6c0b2
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39445
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
If there were any errors communicating with the TPM at the OS layer
(open, read, write failures), the library would immediately exit, not
allowing the caller to make any decisions about how to handle it. This
introduces a way to initialize the library so that errors will get passed
back up to the caller instead of unceremoniously exiting.
Setting the environment variable "TPM_NO_EXIT=1" enables the feature. To
avoid needing to implement supporting functions in all backends, the
feature is currently limited to just the Tlcl stub implementation.
In the case of mount-encrypted, it can now survive the kernel returning
read/write failures. In the past it had only worked around having open
fail, but that has now been replaced with more sensible logic instead of
the environment variable trickiness.
BUG=chrome-os-partner:15960
TEST=daisy built with an always-failing kernel driver, u-boot builds too
BRANCH=None
Change-Id: Ic7b217017537980f9c239d678067398613045676
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38791
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
In the case of the TPM getting into a permanent failure mode
(e.g. crosbug.com/p/15785), the entropy system was not trying harder to
get entropy (i.e. falling back to system RNG), and was just using
whatever happened to be on the stack.
This adds the system RNG to the fallback list:
- try TPM RNG
- try system RNG
- use uninitialized stack contents
The reason for the last one being used is so we can make sure we're
getting a system up. It is extremely unlikely for both the TPM and
the system RNGs to be broken and if they are, it's likely a relatively
permanent failure condition. If we abort in this state, we'll cause an
infinite repair loop which is a very bad user experience. Instead, get
the system up using terrible entropy so the conditions can be examined.
BUG=chrome-os-partner:15960
TEST=daisy build with instrumented kernel tpm driver to always fail
BRANCH=none
Change-Id: I92c454925a78bb0d94262cdb3914c1b72010450e
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38751
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
To help identify the specific failure conditions encountered when the
TPM goes weird, report them any time they are encountered.
BUG=chrome-os-partner:15960
TEST=daisy build, manual testing
BRANCH=none
Change-Id: I80b3bd23c88c19d807cbcafe8ea2736fe000e1d6
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38468
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Libraries must come after objects when linking. Otherwise their
references will be elided when earlier objects didn't need them.
BUG=None
TEST=`LDFLAGS=-Wl,--as-needed emerge-daisy vboot_reference` worked
BRANCH=None
Change-Id: Ic8237a767758d002cd848ed3293b17940884b609
Reviewed-on: https://gerrit.chromium.org/gerrit/37166
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Instead of fsid, which is unpopulated for tmpfs, use device number
since that will increment for each different tmpfs.
BUG=chrome-os-partner:15192
TEST=parrot build, manual testing
BRANCH=none
Change-Id: I0024f7283c90684daaf1278d3cf6b76cc85bb253
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35615
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Elly Jones <ellyjones@chromium.org>
While not having a TPM was supported for non-Chrome devices, it was not
expected for Chrome devices. This adds logic to fail the TPM calls
before making them when the TPM is missing. The tpm_lite library doesn't
handle the TPM being missing, so we have to do this ourselves.
BUG=chrome-os-partner:15192
TEST=parrot build, verified operation after "mv /dev/tpm0 /dev/tpm0.bak"
BRANCH=none
Change-Id: I2f625305dce7fa698fcad33e412ee37c60da9bc2
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35440
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Currently vbutil_what_keys only displays the kernel keyblock info for disk
images. This adds a -v option (requiring sudo) to cause it to attempt to look
inside any rootfs partitions and extract the BIOS image from the shellball.
This CL also updates the list of known sha1sums.
Without -v:
vbutil_what_keys recovery_image.bin
IMAGE: recovery_image.bin
part 2 kernel: 49d40533b0812d3f31232c5eedd47e7e11acc293 (!DEV DEV REC)
part 4 kernel: cc887372ac2d1c415eac93fc11e753629c387358 (!DEV DEV !REC)
With -v:
vbutil_what_keys -v recovery_image.bin
IMAGE: recovery_image.bin
part 2 kernel: 49d40533b0812d3f31232c5eedd47e7e11acc293 (!DEV DEV REC)
part 4 kernel: cc887372ac2d1c415eac93fc11e753629c387358 (!DEV DEV !REC)
part 3 shellball:
hwid: X86 LUMPY TEST 6638
recovery key: 0d800afb53cdd05dd849addee0143ca1d96e893c
root key: 4e92f07efd4a920c4e4f1ed97cf47b7b04ee1428
BUG=none
BRANCH=none
TEST=manual
This is an optional feature to a debugging utility. You can try the examples
above if you feel like testing it yourself.
Change-Id: Ie0dc918c1a99705c408314e960f4dc98aee7c1a9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34537
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This option is disabled per default and can be enabled with
crossystem dev_boot_legacy=1
or by setting the GBB flag
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080
BUG=chrome-os-partner:6108
TEST=crossystem dev_boot_legacy=1
boot to dev mode screen, press CTRL-L, see SeaBIOS start
(other CLs needed)
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38
Reviewed-on: https://gerrit.chromium.org/gerrit/31265
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
A shortcut and easier way to enable USB booting without always calling the huge
firmware updater.
BRANCH=none
BUG=none
TEST=./enable_dev_usb_boot # successfully set dev_usb_boot value.
Change-Id: I9ebb3ce79ef58bc0a32926866d5e1827a92b6e74
Reviewed-on: https://gerrit.chromium.org/gerrit/33046
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Block devices return a size of 0 when stat'ed.
In order to be able to verify directly a raw partition, let's add a
special case to query the block device size.
BUG=chromium-os:34176
TEST="vbutil_kernel --verify /dev/sda4 --verbose" shows the actual
content not an error message.
BRANCH=none
Change-Id: Ibecf0a88816abf97305f0f87c0131ba7b66e386c
Reviewed-on: https://gerrit.chromium.org/gerrit/32302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
We need to know not only whether the HW WP pin is asserted, but whether the
flash chip has configured its software protection registers to actually
protect anything. This flag can be used to indicate that.
BUG=chrome-os-partner:13265
BRANCH=link
TEST=none
This just adds the flag. Nothing actually sets the flag yet, so there's
nothing to test.
Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31642
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the --signprivate_pem option is used to vbutil_keyblock and without
an external signer, we were passing the wrong name to PrivateKeyReadPem()
causing all such invocations to fail. This CL fixes the typo.
(This particular path isn't current being used.)
BUG=none
TEST=manually verified with --signprivatekey_pem but without --external_signer.
BRANCH=none
Change-Id: I56df76a965706f654df1de8ac6e42738c15284c7
Reviewed-on: https://gerrit.chromium.org/gerrit/31556
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
On very large HDDs, the sector count was wrapping around. Switch most
calculations to bytes using uint64_t, and use BLKGETSIZE64 for checking
the loopback device size.
BUG=chrome-os-partner:12705
TEST=parrot build, manual testing
STATUS=Fixed
Change-Id: I1f7aea81151ed5cc130b1f6a05fda83f7a85150f
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31073
Reviewed-by: Elly Jones <ellyjones@chromium.org>
BUG=none
BRANCH=none
TEST=manual
Use it to dump the FMAP from a firmware image:
dump_fmap -h /build/link/firmware/image-link.bin
Change-Id: I94fb9396ea886b072845fadef6ef1e1e2ff85a59
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30784
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mkfs.ext4 does not use the resize= hint for calculating inode ratios.
This means very tiny initial filesystems will not get enough inodes
once it has been resized. This calculates the desired inode ratio based
on the expected final size of the filesystem.
BUG=chrome-os-partner:12678
TEST=lumpy build, manual testing
STATUS=Fixed
Change-Id: I216aaaa6e0ef50e82265ee46ecac5a65bb077387
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30579
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
This adds two new flags to crossystem:
clear_tpm_owner_request
clear_tpm_owner_done
The first one requests that the firmware clear the TPM owner on the
next boot. When the firmware does this, it will set
clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can
use the done-flag as a hint that trusted things guarded by the TPM are
no longer trustable.
BUG=chromium-os:31974
TEST=manual
crossystem
// both flags initially 0
crossystem clear_tpm_owner_request=1
crossystem clear_tpm_owner_done=1
// request=1, done=0; done can be cleared but not set by crossystem
reboot
tpmc getownership
// owned=no
crossystem
// request=0, done=1
crossystem clear_tpm_owner_done=0
crossystem
// both flags 0 again
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd
Reviewed-on: https://gerrit.chromium.org/gerrit/25646
Libraries (-llzma, -lyaml) should be in end of dependency list, otherwise
linking in static mode (-static) would fail.
BUG=none
TEST=emerge vboot_reference
Change-Id: Idd072443d042edfb214f5a958abd064bc18573ed
Reviewed-on: https://gerrit.chromium.org/gerrit/29738
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
The encrypted partition has been plagued with TPM problems, which means
systems that have a wedged TPM, or interrupt the TPM Ownership, Lockbox
creation, etc, all fail to keep the encrypted partition across a reboot.
As a result, we're forced to write the encryption key to disk initially,
and then throw it away once the system key from NVRAM can be used to
encrypt it.
On most systems that have a sane unowned TPM, the key will only be on
disk until the first login finishes and Cryptohome can Finalize the
NVRAM area. For all the other systems, they will continue to run, but
with their encryption key effectively in the clear. Technically, this
is not a regression from R21, so at least we can move forward and work
to improve this in the future.
Some attempt is made to wipe out the key, but this is especially ugly for
SSDs, since doing a "shred" just means the blocks will get moved around.
When ext4 supports "secure delete", we can move to that instead.
BUG=chromium-os:32951
TEST=alex build, manual testing
Change-Id: I9b9a0190ea0f47a277a150eb0882e4a507ff2927
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29123
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
When factory install happens, mount-encrypted is running on a tmpfs,
which can be detected via a W_OK check on the root filesystem.
BUG=chrome-os-partner:12033
TEST=alex build, manual test
Change-Id: I7bf5eaa244a50dd2a0de51760c964e970fa8e3aa
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28960
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Force mode of created key file to 0600, and make sure there is enough
room in the decryption buffer for any possible change to the decryption
algo.
BUG=None
TEST=alex build, manual testing
Change-Id: I89dceec22683ff66b5e1f61a63f14a1db1c4e2ee
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28892
Reviewed-by: Elly Jones <ellyjones@chromium.org>
If the config file is specified in the parameter list but we aren't able
to open (or read) the file, vbutil_kernel should return an error instead
of crashing with a Segmentation Fault.
BUG=chromium-os:33087
TEST=manual
Invoke vbutil_kernel with a bogus path for the config file (--config).
Change-Id: I32dab7c381b9094f4015a554bc59989f1bb329ef
Signed-off-by: Lucian Cojocar <cojocar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28740
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a Cr48 was upgraded from pre-R12, it will lack an NVRAM lockbox area
with no way to create one (TPM password has been thrown away already).
Detect this case and allow fallback to the other system key methods. If
it is a Cr48 running a modern OOBE, treat it like any other device and
require a modern NVRAM lockbox area.
BUG=chromium-os:32766
TEST=mario build, verified OOBE doesn't repeat, simulated pre-R12 uses UUID.
Change-Id: I2acf7ad8c5d16b1f314ba16c673fa3979a40f3de
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28231
Reviewed-by: Elly Jones <ellyjones@chromium.org>
EC FMAP has changed its section names because B partition has been removed. The
signing tool should now use area names "FW_MAIN" and "VBLOCK".
BUG=chrome-os-partner:11360
TEST=emerge-link vboot_reference
Change-Id: I41ff17257b5e2c8a0f4adb11088e121f94e93923
Reviewed-on: https://gerrit.chromium.org/gerrit/27970
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
