The AP sends the Cr50 a request to enable the new firmware image. If
the new Cr50 image was found and enabled, the AP expects the Cr50 to
reset the device in 1 second.
While waiting for the Cr50 to reset, the AP logs a newly defined event
and optionally shuts down the system. By default the x86 systems power
off as shutting those systems down is not board specific.
BRANCH=gru,reef
BUG=b:35580805
TEST=built a reef image, observed that in case cr50 image is updated,
after the next reboot the AP stops booting before loading depthcharge,
reports upcoming reset and waits for it.
Once the system is booted after that, the new event can be found
in the log:
localhost ~ # mosys eventlog list
...
7 | 2017-03-23 18:42:12 | Chrome OS Developer Mode
8 | 2017-03-23 18:42:13 | Unknown | 0xac
9 | 2017-03-23 18:42:21 | System boot | 46
...
Change-Id: I45fd6058c03f32ff8edccd56ca2aa5359d9b21b1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The CR50 TPM can do both SPI and I2C communication. However,
there's situations where policy needs to be applied for CR50
generically regardless of the I/O transport. Therefore add
MAINBOARD_HAS_TPM_CR50 to encompass that. Additionally,
once the mainboard has selected CR50 TPM automatically select
MAINBOARD_HAS_TPM2 since CR50 TPM is TPM 2.0.
Change-Id: I878f9b9dc99cfb0252d6fef7fc020fa3d391fcec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19370
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This callback was only required for a single mainboard, and it can
easily be moved to mainboard-specific code. This patch removes it from
the global namespace and isolates it to the Jecht board. (This makes
it easier to separate vboot and chromeos code in a later patch.)
Change-Id: I9cf67a75a052d1c86eda0393b6a9fbbe255fedf8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18981
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The virtualized developer switch was invented five years ago and has
been used on every vboot system ever since. We shouldn't need to specify
it again and again for every new board. This patch flips the Kconfig
logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with
CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to
set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the
latter for Lumpy which seems to have been omitted incorrectly, and hide
it from menuconfig since it's a hardware parameter that shouldn't be
configurable.)
Since almost all our developer switches are virtual, it doesn't make
sense for every board to pass a non-existent or non-functional developer
mode switch in the coreboot tables, so let's get rid of that. It's also
dangerously confusing for many boards to define a get_developer_mode()
function that reads an actual pin (often from a debug header) which will
not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set.
Therefore, this patch removes all those non-functional instances of that
function. In the future, either the board has a physical dev switch and
must define it, or it doesn't and must not.
In a similar sense (and since I'm touching so many board configs
anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC.
Instead, it should just be assumed by default whenever a Chrome EC is
present in the system. This way, it can also still be overridden by
menuconfig.
CQ-DEPEND=CL:459701
Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18980
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The correct way to mock out vboot TPM accesses these days is the
CONFIG_VBOOT_MOCK_SECDATA Kconfig option. There are some remnants of
older TPM-mocking infrastructure in our codebase that are as far as I
can tell inert. Remove them.
Change-Id: I3e00c94b71d53676e6c796e0bec0f3db67c78e34
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18977
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
cr50 by default delays nvmem commits internally from the point of
reset to accumulate change state. However, the factory process can
put a board into dev mode through the recovery screen. This state
is stored in the TPM's nvmem space. When the factory process is
complete a disable_dev_request and battery_cutoff_request is performed.
This leads to disabling the dev mode in TPM, but the battery is
subsequently cut off so the nvmem contents never stick. Therefore,
whenever antirollback_write_space_firmware() is called we know there
was a change in secdata so request cr50 to immediately enable nvmem
commits going forward. This allows state changes to happen immediately.
The fallout from this is that when secdata is changed that current
boot will take longer because every transaction that writes to TPM
nvmem space will perform a write synchronously. All subsequent boots
do not have that effect.
It should also be noted that this approach to the implementation is
a pretty severe layering violation. However, the current TPM APIs
don't lend themselves well to extending commands or re-using code
outside of the current routines which inherently assume all knowledge
of every command (in conflict with vendor commands since those are
vendor-specific by definition).
BUG=b:35775104
BRANCH=reef
TEST=Confirmed disablement of dev mode sticks in the presence of:
crossystem disable_dev_request=1; crossystem
battery_cutoff_request=1; reboot;
Change-Id: I3395db9cbdfea45da1f5cb994c6570978593b944
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18681
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
The event log entry indicating developer mode is useful for the
boot path, but is not really useful on the resume path and removing
it makes the event log easier to read when developer mode is enabled.
To make this work I have to use #ifdef around the ACPI code since
this is shared with ARM which does not have acpi.h.
BUG=b:36042662
BRANCH=none
TEST=perform suspend/resume on Eve and check that the event log
does not have an entry for Chrome OS Developer Mode.
Change-Id: I1a9d775d18e794b41c3d701e5211c238a888501a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18665
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This reverts commit 580db7fd90.
There's a (parallel) mechanism more closely aligned with how the values
are filled in (fixed device part + version string) that landed from
Chrome OS downstream (see commit 4399b85fdd).
Change-Id: I5ccd06eadabb396452cc9d1d4dff780ea0720523
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18205
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
On Chrome OS devices that use TPM2 parts the platform hierarchy
is disabled by the boot loader, depthcharge. Since the bootloader
isn't involved in resuming a suspended machine there's no equivalent
action in coreboot to disable the platform hierarchy. Therefore, to
ensure consistent state in resume the platform hierarchy in the TPM2
needs to be disabled as well. For systems that resume using the
firmware the platform hierarchy is disabled when utilizing
TPM2 devices.
BUG=chrome-os-partner:61097
BRANCH=reef
TEST=Suspend and resume. Confirmed 'stop trunksd; tpmc getvf; start
trunksd' shows that phEnable is 0.
Change-Id: I060252f338c8fd68389273224ee58caa99881de8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18096
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Build issues were somehow overlooked in commit
ed840023a8:
1. hexstrtobin is not defined (needs the lib.h);
2. coreboot default compiler doesn't like variable initialization
within for loop.
BUG=chrome-os-partner:60821
TEST=Build and boot lars and reef
Change-Id: Ie52c1f93eee7d739b8aaf59604875f179dff60d0
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-on: https://review.coreboot.org/18076
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A VPD entry "wifi_sar" needs to be created which contains a heximal
encoded string in length of 40 bytes. get_wifi_sar_limits() function
retrieves and decodes the data from the VPD entry, which would later
be consumed by platform code.
BUG=chrome-os-partner:60821
TEST=Build and boot lars and reef
Change-Id: I923b58a63dc1f8a7fdd685cf1c618b2fdf4e7061
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-on: https://review.coreboot.org/17958
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the factory it's helpful for knowing when a system being
built is meant for release with all the security features
locked down. Provide support for exporting this type of pin
in the acpi tables.
BUG=chrome-os-partner:59951
BRANCH=reef
Change-Id: Iec70249f19fc36e5c9c3a05b1395f84a3bcda9d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17802
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chromium:595715
BRANCH=none
TEST=/build/$board/firmware/coreboot.rom has a zeroed out SHARED_DATA
region if it exists.
Change-Id: Ib1e6fd62bcf987872890c6d155287dcedb0b1f40
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e8a88bf744f44d034f8606a556014e2bee37eda1
Original-Change-Id: I0b59f1f0e2f8645000f83cb3ca7f49e4da726341
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/417821
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://review.coreboot.org/17789
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Chrome OS images have three firmware ID regions, to store version
information for the read-only and the two read-write areas. Fill them
with a suitable default and allow configuring a different scheme.
There's already an override in google/foster and google/rotor to match
the naming scheme used so far (in depthcharge).
BUG=chromium:595715
BRANCH=none
TEST=/build/$board/firmware/coreboot.rom has the expected values in the
regions.
Change-Id: I5fade5971135fa0347d6e13ec72909db83818959
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d2e3be81faa8d21f92325294530714a4b18a1b3e
Original-Change-Id: I2fa2d51eacd832db6864fb67b6481b4d27889f52
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/417320
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://review.coreboot.org/17788
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of defining the same functions for reading/clearing boot-mode
switches from EC in every mainboard, add a common infrastructure to
enable common functions for handling boot-mode switches if
GOOGLE_CHROMEEC is being used.
Only boards that were not moved to this new infrastructure are those
that do not use GOOGLE_CHROMEEC or which rely on some mainboard specific
mechanism for reading boot-mode switches.
BUG=None
BRANCH=None
TEST=abuild compiles all boards successfully with and without ChromeOS
option.
Change-Id: I267aadea9e616464563df04b51a668b877f0d578
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17449
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Provide an option to deliver the mainboard smbios version in the
form of 'rev%d' based on the board_id() value.
BUG=chromium:663243
Change-Id: If0a34935f570612da6e0c950fd7e8f0d92b6984f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17290
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
However, the latter still has some 'select' clauses to ensure that
required TPM libraries are built. The TPM is an essential part of vboot,
and without these libraries the vboot code cannot compile... therefore,
they should be moved under CONFIG_VBOOT.
Change-Id: I0145558e5127c65c6a82d62f25b5a39e24cb8726
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16229
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This option is no longer used in the code base. Remove it.
BUG=chrome-os-partner:56151
Change-Id: Ia73cce7546c9839518c9e931b03c50856abc2018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16186
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch enables the CHROMEOS_RAMOOPS_NON_APCI Kconfig option as a
default across all non-x86 Chrome OS boards.
CQ-DEPEND=CL:367905
BRANCH=None
BUG=None
TEST=See depthcharge CL.
Change-Id: If14ef4f9b1bd480f2d52df3892c73059bb9b07d5
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 8c3b74fb21aadd6de7af62f32fa98fc211d75085
Original-Change-Id: I16ff7f68762a995cd38e5fddaf6971d4b9f07e21
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/368010
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16154
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This replaces all occurrences of a hardcoded vboot path to the
VBOOT_SOURCE variable, that may be overridden from the command line,
witch fallback to the source from 3rdparty.
Change-Id: Ia57d498d38719cc71e17060b76b0162c4ab363ed
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use the ACPI generator for creating the Chrome OS gpio
package. Each mainboard has its own list of Chrome OS
gpios that are fed into a helper to generate the ACPI
external OIPG package. Additionally, the common
chromeos.asl is now conditionally included based on
CONFIG_CHROMEOS.
Change-Id: I1d3d951964374a9d43521879d4c265fa513920d2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15909
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
1. Currenty, boot reason is being added to elog only for some
ARM32/ARM64 platforms. Change this so that boot reason is logged by
default in elog for all devices which have CHROMEOS selected.
2. Add a new option to select ELOG_WATCHDOG_RESET for the devices that
want to add details about watchdog reset in elog. This requires a
special region WATCHDOG to be present in the memlayout.
3. Remove calls to elog add boot reason and watchdog reset from
mainboards.
BUG=chrome-os-partner:55639
Change-Id: I91ff5b158cfd2a0749e7fefc498d8659f7e6aa91
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use
of verified boot library without having to stick to CHROMEOS.
BUG=chrome-os-partner:55639
Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15867
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This renames the VB_SOURCE variable to VBOOT_SOURCE in the build system,
providing increased clarity about what it represents.
Since the submodule itself is called "vboot", it makes sense to use that
name in full instead of a very shortened (and confusing) version of it.
Change-Id: Ib343b6642363665ec1205134832498a59b7c4a26
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15824
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On some x86 platforms (skylake, apollolake), we observe reboots at
different steps during the FSP initialization. These additional reboots
result in loss of recovery request because vboot_reference library
clears recovery request on vbnv once verification is complete and it has
made a decision about which boot path to take(normal/dev, slot-a/slot-b,
recovery).
Provide a way to allow mainboards/chipsets to inform recovery module in
vboot2 to save recovery reason to survive unexpected reboots. The
recovery reason is set in vbnv after vboot_reference library completes
its verification and clears the reason in vbnv while jumping to
payload.
BUG=chrome-os-partner:55431
Change-Id: Ie96be9aeb42c8209d8215943409e6327d6a8bf98
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15802
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add recovery module in vboot2 that checks if a recovery request is
pending and returns appropriate reason code:
1. Checks if recovery mode is initiated by EC.
2. Checks if recovery request is present in VBNV.
3. Checks if recovery request is present in handoff for post-cbmem
stages.
4. Checks if vboot verification is complete and looks up selected region
to identify if recovery is requested by vboot library.
BUG=chrome-os-partner:55431
Change-Id: I31e332a4d014a185df2434c3730954e08dc27281
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This fills up the RO_FRID, RW_FWID_A and RW_FWID_B FMAP sections with
the relevant version from KERNELVERSION, padded to the right size and
gap-filled with zeros.
Change-Id: I45c724555f8e41be02b92ef2990bf6710be805c2
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15604
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I52aa8db95b908488ec4cf0843afeb6310dc7f38b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2f859335dfccfeea900f15bbb8c6cb3fd5ec8c77
Original-Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: Ia431390870cbe448bc1b6f1755ed17953be9bdf1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 347ff17b97da45fa4df547ff32f9dd2c8972cefd
Original-Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358095
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15636
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Original-Commit-Id: 5f082d6a9b095c3efc283b7a49eac9b4f2bcb6ec
Original-Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353916
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
squashed:
mock tpm: drop unused functions
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Original-Commit-Id: c6d7824f52534ecd3b02172cb9078f03e318cb2b
Original-Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356291
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb686c5f9129067eb4bb3ea10bbb85a075b29955
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15571
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If read_vbnv finds that the vbnv_copy is not valid, it initializes it
with the correct HEADER_SIGNATURE and other attributes. However, the
vbnv copy is checked for validity and initialized at the vboot layer as
well. Since, vboot is the owner of this data, it should be the one
initializing it. Thus, if read_vbnv sees that the data is not valid,
simply reset it to all 0s and let vboot layer take care of it. This also
removes the need for additional checks to ensure that the dirty vbnv
copy is properly updated on storage.
Change-Id: I6101ac41f31f720a6e357c9c56e571d62e0f2f47
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Currently, read_vbnv performs a reset of the vbnv cache if it is not
valid. However, this information is not passed up to the vboot layer,
thus resulting in missed write-back of vbnv cache to storage if vboot
does not update the cache itself.
Update read_vbnv to return a value depending upon whether it wants a
write-back to be performed when save is called.
Return value:
0 = No write-back required
1 = Write-back of VBNV cache is required.
Change-Id: I239939d5f9731d89a9d53fe662321b93fc1ab113
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1
Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349850
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15294
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The VBOOT_OPROM_MATTERS configuration option signals to vboot that the
board can skip display initialization in the normal boot path. It's name
is a left-over from a time when this could only happen by avoiding
loading the VGA option ROM on x86 devices. Now we have other
boards that can skip their native display initialization paths too, and
the effect to vboot is the same. (Really, we should rename oprom_matters
and oprom_loaded to display_skippable and display_initialized or
something, but I don't think that's worth the amount of repositories
this would need to touch.)
The only effect this still has in today's vboot is to reboot and
explicitly request display initialization for EC software sync on
VBOOT_EC_SLOW_UPDATE devices (which we haven't had yet on ARM). Still,
the vboot flag just declares the capability (for skipping display init),
and it should be set correctly regardless of whether that actually makes
a difference on a given platform (right now). This patch updates all
boards/SoCs that have a conditional path based on
display_init_required() accordingly.
BRANCH=None
BUG=chrome-os-partner:51145
TEST=Booted Oak, confirmed that there's no notable boot time impact.
Change-Id: Ic7c77dbd8356d67af7aee54e7869f9ac35241b99
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9c242f7
Original-Change-Id: I75e5cdda2ba2d111ea50ed2c7cdf94322679f1cd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/348786
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When the vboot cbfs selection runs in postcar stage it should be
utilizing cbmem to locate the vboot selected region.
Change-Id: I027ba19438468bd690d74ae55007393f051fde42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14959
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Using a dedicated variable is slightly less readable and makes the code
less consistent, given that other test functions are called directly in
the if statements.
Change-Id: If52b2a4268acb1e2187574d15cc73a0c1d5fe9bb
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
