| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add FE_LOG_FIPS_FAILURE event type
BUG=b:138577539
TEST=manual
Signed-off-by: Vadim Sukhomlinov <sukhomlinov@google.com>
Change-Id: I11be32598ddbbb327175a656c21abcb8388246d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2247106
Reviewed-by: Vadim Sukhomlinov <sukhomlinov@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Auto-Submit: Vadim Sukhomlinov <sukhomlinov@chromium.org>
Commit-Queue: Vadim Sukhomlinov <sukhomlinov@chromium.org>
Tested-by: Vadim Sukhomlinov <sukhomlinov@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When AP RO verification is attempted, a lot of thing could go wrong,
and the operator would usually have very little insight into what's
happening unless there is a terminal connected to the Cr50 console.
This patch adds a new log event for registering the AP RO verification
progress. The event payload is a single byte value, logging the
following events:
0 - refresh key press is detected
1 - power button has been released before AP RO check was triggered
2 - trigger sequence timeout (refresh button not pressed in time)
3 - AP RO check triggered
4 - could not run the check, hash space not programmed
5 - could not run the check, hash space corrupted
6 - AP RO verification failed
7 - AP RO verification succeeded
BUG=b:153764696
TEST=verified logging during various AP RO verification attempts:
$ gsctool -a -L
Log time zone is PST
Dec 31 69 16:00:01 : 00
May 06 20 21:20:49 : 09 01
May 06 20 21:21:53 : 09 00
May 06 20 21:21:54 : 09 00
May 06 20 21:21:55 : 09 03
May 06 20 21:21:56 : 09 07
May 06 20 21:23:03 : 09 00
May 06 20 21:23:04 : 09 00
May 06 20 21:23:05 : 09 02
May 07 20 11:21:52 : 09 00
May 07 20 11:21:53 : 09 00
May 07 20 11:21:54 : 09 01
May 08 20 11:57:21 : 09 00
May 08 20 11:57:22 : 09 00
May 08 20 11:57:23 : 09 03
May 08 20 11:57:24 : 09 04
May 08 20 12:07:15 : 09 00
May 08 20 12:07:16 : 09 00
May 08 20 12:07:17 : 09 03
May 08 20 12:07:19 : 09 07
May 08 20 12:09:20 : 09 00
May 08 20 12:09:21 : 09 00
May 08 20 12:09:22 : 09 03
May 08 20 12:09:23 : 09 06
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: I739f9dbb2e7b8fc87601d61e1f87eb49d85bdf14
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2191283
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is an NVMEM corruption which causes a reboot, persisting
corruption would cause rolling reboot of the device.
It is a harsh remedy, but at least the device remains functional.
Added a log entry to explicitly report NVMEM reinitialization.
BRANCH=cr50, cr50-mp
BUG=b:139326267
TEST=verified by erasing a flash page assigned to NVMEM and rebooting
the device. Observed two new flash log entries.
Change-Id: Id292d7c66b81c03bbe3cd343ae75acb62d06582d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1758805
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case power was lost when saving an object spanning two pages, the
initialization process does not return the second flash page into the
pages pool, leaving NVMEM in an inconsistent state.
Proper recovery should reinitialize the second page and return it into
the pool of available flash pages.
If a failure like this happens, to recover the initialization sequence
will have to run one extra cycle, first one bringing the NVMEM state
to the previously covered state of the last object in NVMEM corrupted,
but fitting into a page.
A unit test added to verify proper behavior in this situation.
BRANCH=cr50, cr50-mp
BUG=b:139326267
TEST='make run-nvmem -j' passes. Also added temporary code cause reset
when saving the second part of an object spanning two flash
pages. Observed the device properly recover from this failure.
Change-Id: I76ebb6fc73ffc0b07bce34370302f3787914bfb2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1766092
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to keep an eye on the dcrypto failures (which are never
supposed to happen of course). Let's add logging a flash event so that
the failures are visible through UMA.
BRANCH=cr50, cr50-mp
BUG=b:135772657
TEST=using additional code simulated a single failure, observed new
flash log entry by running 'gsctool -a -L' on the DUT.
Change-Id: Ib675bb1928166cadc069bf4be3b053a9cf837077
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1723097
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to track TRNG stalls happening in the field. This
patch adds a log message to report detected TRNG stalls. The code
detecting the stall is being modified to monitor a different status
bit as per chip designer recommendation.
A console command allowing to test TRNG is being added, compiled in
only if TEST_TRNG is defined.
BRANCH=cr50, cr50-mp
BUG=b:27646393
TEST=compiled the test command in, ran the command
rand 10000000
several times, observed reasonable stats and no stall reports.
Change-Id: Idcf83ff2c41e23f601b8da8c46fa4d4d1cde0270
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1601470
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Cr50 environment does not have a wall clock, which makes it
impossible to associate flash log entries with real time.
This patch provides an API which allows to set a base time value and
then use it plus current Cr50 uptime to generate more sensible flash
log timestamps.
Care is taken to ensure that attempts to set timestamp base such that
it would cause a log timestamps rollback do not succeed.
A unit test is being added to verify this behavior.
BRANCH=none
BUG=b:132287488
TEST='make buildall -j' (which runs the new tests) succeeds.
Change-Id: I7521df1bac5aef67e0cf634c183bf1618655f48d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1610719
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just in case there is a failure when encrypting or decrypting NVMEM
objects, add code which detects problems, reports them in the flash
log and reboots.
BRANCH=cr50, cr50-mp
BUG=b:69907320, b:129710256
TEST=none
Change-Id: I22e55941f459b5b45bf4b23781b20601a56b40d8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1590042
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were clearing the tpm in two different ways. There was one
implementation in factory_mode.c and one in wp.c. This change merges the
two, so there's only one board_wipe_tpm.
While modifying the wipe tpm code from factory_mode.c I noticed the
factory_enable_failed stuff is maybe a bit more complicated than
necessary. I opened a bug for cleaning that up(b/129956462). It wont be
addressed in this change.
BUG=none
BRANCH=none
TEST=Run the processes that wipe the tpm
open ccd.
enable factory mode from vendor command.
run rma open process
Change-Id: Ia76df19f7d9e4f308f3f1a7175f130f1ef7249a2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1535156
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a proposed implementation of the new TPM NVMEM flash
layer.
There is a big comment block in common/new_nvmem.c describing the
approach taken, changes to the API and outstanding issues.
This implementation follows the design document attached to
b:69907320.
With all required changes to the rest of the code this new flash
storage scheme consumes 7816(!) bytes of code storage.
One of the more important aspects of this implementation is that the
(key, value) pair objects are stored in the flash only, they are not
duplicated in the SRAM cache. The advantage of this is that there
could be more space dedicated to these objects. Soft limit is set to
1K as opposed to 272 bytes available with the legacy scheme. The major
disadvantage is the need for the user not to forget to release the
(key, value) pair retrieved from NVMEM, as it occupies space on the
heap.
BRANCH=cr50, cr50-mp
BUG=b:69907320, b:129710256
TEST=with the rest of the patches applied the following tests pass:
- test cases in ./test (completely reworked for the new scheme)
- TCG suite (passes on par with the existing Cr50 code with the
reduced code footprint TPM2 library)
- Chrome OS device migrates from legacy to new implementation with
user account maintained.
- Chrome OS user account is maintained over AP and H1 reboots and
deep sleep cycles.
Change-Id: I6252649597c03abd4a08e2d55d61e384fe037ef7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1450277
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
|
This patch adds implementation and test for a generic logger saving
log entries in the flash.
The entries payload are limited to 64 bytes in size, each entry starts
with a header, which includes
- 8 bit type type to allow to interpret the payload
- 6 bit size field (two top bits of the byte are left for user flags,
not yet used)
- 32 bit timestamp to allow to identify newer log entries (presently
this is just a monotonically increasing number)
- 8 bit crc field protecting the entire entry
The entries are padded to make sure that they are ending on the flash
write boundary.
The location of the log is defined by the platform using it. There is
a provision for allowing the platform to register a callback which is
needed to be called to allow write access to the log (as is the case
on H1).
While the device is running, the log is growing until the allotted
flash space is 90% full. If there is an attempt save another entry
after that the log is compacted, namely the last 25% worth of flash
space is preserved, the log space is erased and the saved contents
written back.
On restarts the log is compacted if its size exceeds 75% of the
allotted flash space.
An API is provided to add entries to the log and to retrieve an entry
newer than a certain timestamp value. Thus starting with timestamp
zero will result in reading the very first log entry. To read the next
entry, the read function needs to be called with the timestamp value
of the current entry. This allows to browse the entire log, one entry
at a time.
A CLI command compiled in when CONFIG_CMD_FLASH_LOG is defined, allows
to add log and retrieve log entries.
BUG=b:63760920
BRANCH=cr50, cr50-mp
TEST=the included test case can be invoked by
make run-flash_log
and it passes. More tests are done when the rest of the patch stack
is added.
Change-Id: I3dcdf2704a1e08fd3101183e434ac4a4e4cf1b9a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
