tree 688b8edd8b1aa58cf0ee4f4ad11002d5dd0dd74b
parent 7141d73c149ee203a192f0cb45ca9bfa10c0ff8c
author Bill Richardson <wfrichar@chromium.org> 1401317363 -0700
committer chrome-internal-fetch <chrome-internal-fetch@google.com> 1402010139 +0000

Use the TPM to back up some of the nvram fields

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>