The TPM SPI protocol adds flow control capability, but it is
impossible to enforce it by software, software implementations need
additional means of informing the master about the slave status.
Let's follow the i2c slave driver example and use the interrupt line
from the H1 to the SOC to generate a low level pulse every time
receive data processing is completed.
BRANCH=none
BUG=none
TEST=to benefit from this patch some changes on the SOC side will be
required.
Change-Id: I576233598e98e01a007dff6b973fd96ea5ea551c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446048
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch introduces a delay between accepted cr50 firmware upload
attempts. The next attempt to write into the same or lower address in
flash would be accepted no sooner than in 60 seconds after the
previous attempt.
This would prevent a rogue user from wearing the flash by repeated
uploads to the same address.
This limitation is not imposed by dev images (those compiled with
CR50_DEV=1).
BRANCH=none
BUG=chrome-os-partner:63098
TEST=verified that attempts to update soon after the previous update
result in the following error message issued by usb_updater:
sending 0x2d8b8 bytes to 0x4000
Error: status 0x9
Modified usb_updater to send one random pdu twice. Observed the
same error message.
Change-Id: Idca55ad091d09daaddd0a4cad5b1f871af1ede93
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445496
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Let's not allow downloading older images when in prod mode.
When the received chunk is destined into RO or RW header, verify that
the chunk's version is not lower than the current running version.
Also, if the chunk is not properly aligned with the header, verify
that it does not overlap with the header in any way.
BRANCH=none
BUG=chrome-os-partner:63098
TEST=verified that older images are rejected by prod images, and newer
and current level are accepted.
Verified that dev images still allow to downgrade.
Change-Id: I19c74f1d1bb5469cc935293a5841405149a968f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/444831
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Presently the CR50_DEV make variable is loaded: it enables debug
extensions in the produced cr50 image AND requires that the image is
signed with the key from the signing fob.
In fact these are two independent requirements: it is possible to use
an image built with CR50_DEV set for a dev H1 which does not require
fob signing.
A proper indication of the need to use the signing fob would be the
fact that H1_DEVIDS is defined, as it means a that node locked image
is being produced.
Images built without H1_DEVIDS set can be used on H1s which run with
the dev RO and as such do not need to be node locked, they are
signed with a well known key from util/signer/loader-testkey-A.pem.
This patch also tweaks passing the H1_DEVIDS variable to the shell
when altering the manifest. Without this tweak H1_DEVIDS definition as
make command line argument (as opposed to environment variable) was
not making it into the subshell invoked by make.
BRANCH=none
BUG=chrome-os-partner:62457
TEST=ran the following:
- built cr50 images with H1_DEVIDS defined in the environment and
in the command line, observed that the properly signed prod
image is produced (boots on a prod H1 in node locked mode).
- verified that adding CR50_DEV=1 to H1_DEVIDS in either
environment or the command line produces a properly signed
DEV image.
- verified that specifying CR50_DEV=1 alone in either environment
of command line produces a DEV image which does not require fob
signing.
Change-Id: Ied65a0bc50926aa5b6fa65e51805c2368522dcf2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434926
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The USB FW upgrade endpoint should really only accept vendor commands
required to perform the firmware update. This commit adds a whitelist
that is checked whenever a vendor command is received over this
endpoint.
The allowed commands over USB are the following:
- EXTENSION_POST_RESET
- VENDOR_CC_IMMEDIATE_RESET (only for dev images)
There is also functionality to have a whitelist for vendor commands that
come over the TPM interface.
BUG=chrome-os-partner:62815
BRANCH=None
TEST=Flash Cr50 with image containing this change. Verify that an
upgrade over USB to newer image works.
TEST=Try using usb_updater to send a vendor command that's not in the
whitelist. Verify that the vendor command is dropped.
Change-Id: I71f8ba090a1cc6c9e7c30ce0dd3c25259e8f292f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/443447
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, manually triggered reboots cause the retry counter to be
incremented. However, if the system is responsive enough to process the
reboot commands from either the console or TPM vendor command, we can
assume that the image is "ok". This commit changes the Cr50 behaviour
to decrement the retry counter when a reboot is issued on the console or
the TPM vendor command is received.
BUG=chrome-os-partner:62687
BRANCH=None
TEST=Flash cr50. Flash an older image in the other slot. Enter the
reboot command on the console over 10 times and verify that retry
counter never exceeds RW_BOOT_MAX_RETRY_COUNT and older image is never
executed.
CQ-DEPEND=CL:444264
Change-Id: Ic35bdc63c4141834584a00a7ecceab2abe8dfc21
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/443330
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In preparation for adding the rollback protection block, pass
EC_FLASH_PROTECT_RO/ALL_AT_BOOT to flash_[physical_]protect_at_boot,
instead of an enumeration no protection/RO/ALL.
This will later allow us to protect/unprotect the rollback region only,
by adding a EC_FLASH_PROTECT_ROLLBACK_AT_BOOT flag.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=Build hammer with CONFIG_CMD_FLASH command, so that write protection
can be checked with flasherase/flashwrite.
TEST=On hammer (stm32f072):
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=On reef (npcx):
deassert WP, flashwp false; flashinfo => RO+RW not protected
flashwp true => only RO protected
reboot => only RO protected
flashwp rw => RO+RW protected
reboot => only RO protected
Change-Id: Iec96a7377baabc9100fc59de0a31505095a3499f
Reviewed-on: https://chromium-review.googlesource.com/430518
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no point in keeping in one file multiple hooks task callbacks
to handle chipset shutdown and resume conditions.
Also, the policy of disabling deep sleep needs to be decided in the
board level hooks.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=ran reef through 200 cycles of suspend/resume
Change-Id: I4d30cd04b986b243a5bea44c6978a5f82f8f62a7
Reviewed-on: https://chromium-review.googlesource.com/437729
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
Being able to determine what sleep state the system is in is very
handy, and reading the state is pretty safe.
Let's declare the idle console command safe and disallow its
parameters when console is locked.
BRANCH=none
BUG=none
TEST=verified that it is possible to read the idle state when console
is locked, but not possible to set it.
Change-Id: I97f680bf033290220a4fa7fd5a7af170736443d8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436905
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The output of pinmux command is garbled (it probably was OK until the
console UART TX buffer was significantly reduced in size by
https://chromium-review.googlesource.com/418948).
Let's flush the console every so often.
Also, fixed the bug where the second GPIO port base address in PIMUX
was off, and added a newline to separate UART section of the output.
BRANCH=none
BUG=none
TEST=ran pinmux command successfully. make -j buildall passes
Change-Id: Iae0dcbbd0a55d704ffe2296d6e0e81b2c6aec527
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436765
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The commit changes the behaviour to block accesses over the USB-SPI
bridge while the console is restricted.
BUG=chrome-os-partner:62340
BRANCH=None
TEST=Build and flash cr50 on snappy; lock console; try to flash EC bin
using CCD. Verify that it fails with flashrom not able to find a flash
chip.
TEST=Disable console lock; Try to flash EC bin; verify it succeeds.
TEST=Repeat above tests but trying to read AP flash instead.
TEST=make -j buildall
Change-Id: Ib69af1a7372d841783acee2262efbf995d031234
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/435437
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The cipher command implementation had to change to account for reduced
heap size and to improve coverage.
Note that the goal of this command is not to verify correctness of the
encryption services provided by the dcrypto, but to allow to exercise
the crypto engine on multiple passes, each time using the same clear
text but different initialization vector.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=ran cipher command on a few devices:
> cip
Will wait up to 4074 ms
running 1000 iterations
blob size 7111 at 1e020
original data 8f3d99fbfcbd26dd0c4d8dc444d106ee
hashed data 826a4e9b04d214fbbd5fbf4e0fba8068
Encryption results: min 1128 us, max 1456 us, average 1180 us
Decryption results: min 1124 us, max 7348 us, average 1193 us
>
Change-Id: Idf72b355dce0f288d4a3d8a065bc08eb9c4f6bc3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434167
Reviewed-by: Nagendra Modadugu <ngm@google.com>
We wanted to reduce the number of interrupts that uart was producing so
we increased the number of characters needed in the fifos before it
would trigger an interrupt. Right now it needs 4 characters. If you
aren't printing a multiple of four characters, then not all text will be
printed.
This change changes the rxilvl back to 1. This will make using the
consoles and testing cr50 functionality more reliable.
BUG=chrome-os-partner:62158
BRANCH=none
TEST=login and boot still work fine. The AP and EC consoles print all
output correctly.
Change-Id: I2d48d02a275173d560c03e5363845a5afc94df7a
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434891
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I49ea5fc27a7f11f66daba485a87d0dfe7d0c770f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/427408
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The previous implementation of DCRYPTO_app_cipher
consumed roughly 16ms to cipher a 16kB buffer
(i.e. performance that is far worse than the
hardware is capable of).
This change speeds up the implementation by about
85%, to the tune of roughly 2.2ms for a 16kB buffer.
The gains originate from various sources: loop
unrolling, data-pipelining, eliminating local
variables (to reduce register pressure), eliminating
support for unaligned input/output data, compiling
hot code with -O (rather the default -Os), and
using the hidden key-ladder, which need only be
setup once per reset.
This change also switches from AES-128 to AES-256.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall succeeds;
cipher command succeeds;
TCG tests pass
Change-Id: I133741be6d9f1353d6ae732d0e863b4b18cc8c9e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/433359
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for verifying messages signed
with 4096-bit RSA keys. Such messages may
be generated by host side applications.
Also update tpmtest.py to test 4k verification.
BRANCH=none
BUG=none
TEST=added new tests to tpmtest.py; TCG tests pass
Change-Id: I7450bd710c154c68c030ce176bfe7becbfbcb729
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/428220
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With introduction of encryption it is becoming impossible to read
NVMEM contents directly from flash. Decrypting the contents each time
there is a read request creates a significant performance hit. NVMEM
needs to be rearchitecture such that there is no need to run
decryption each time NVMEM read is performed.
This patch does just that, implementation details are described in the
header comment in common/nvmem.c.
To reduce memory impact the size of NVMEM is being decreased from 16K
to 12K. This is acceptable because eviction objects stored in NVMEM
serialized now, which dramatically reduces NVMEM size requirements.
The TPM2 NVMEM size definition must be kept in sync.
Another optimization this change introduces is bypassing writing into
the flash if NVMEM contents did not change, which is verified by
examining the hash of the cached storage.
A test is added to verify that the new commit scheme works as
expected, and the nvmem test is re-introduced to the list of test ran
on each 'make buildall'.
CQ-DEPEND=CL:433839
BRANCH=none
BUG=chrome-os-partner:62260,chrome-os-partner:62421
BUG=chrome-os-partner:62437
TEST=ran the following tests, all succeeded
make buildall -j
TEST_LIST_HOST=nvmem make runtests
tcg test suite
corp enroll on reef, reboot a few times, verify that enrollment sticks
Change-Id: I177daa3ceb4fd7aac299ca26b4506b863e31b946
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On boards based on the g chip cryptographic functions come from
hardware, they should be implemented in chip/g as opposed to a
particular board.
The common modules (like nvmem) should be using some generic API,
which hopefully will be implemented by other chips, or could be
replaced by a purely software implementation where crypto hardware
support is not available.
Crypto API definition is being added in include/ and the g chip
implementation (a wrapper around dcrypto functions) is being added in
chip/g.
test/nvmem_vars.h needed to be edited to avoid conflict with
<string.h>.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall -j still passes. Booting reef with the new image
works fine too.
Change-Id: Ifef281215f89239966882ecbe3e90c8351b9b91a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431313
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This change introduces DCRYPTO_app_cipher(), an encrypt/decrypt
function that accepts an IV and corresponding data. Typical
restrictions on IV reuse apply. The key is derived from the hardware
based on the type of the RW image signature (dev vs prod).
A console command is added to exercise the cipher function.
Since stack requirements of the dcrypto code exceed the console task
allowance, the actual command is executed on the HOOKs task context.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=make buildall -j passes. Running the cipher command from the
console succeeds:
> cipher
original data ad67d44cb4feffff6b3b334635eb9612
rv 0x01, out data 861dc395a2fc745ca886a703cb02a897, time 16636 us
rv 0x01, orig. data ad67d44cb4feffff6b3b334635eb9612, time 17004 us
sha1 before and after match!
>
Change-Id: I7686d8c8489c1b8a984859c3be4f82c338573c6f
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Marius Schilder <mschilder@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428171
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Add functions that derive application specific keys based
on FRK2. For the moment, derived keys need to be manually
copied into the AES engine. Since key-ladder state depends
on the code-signer (prod vs. dev), application derived keys
are also different in the two modes. Thus ciphertext blobs
produced by prod-signed code cannot be decrypted by dev-signed
code.
To minimize stack requirements on the hook_task, the SHA
context in DCRYPTO_appkey_init() is placed in allocated/freed
memory. This SHA object will become unnecessary once the
AES engine is seeded directly from the key-ladder.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=pending
Change-Id: Ifb274b15e61be317e02ec31fc52f9a41e06dcba3
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Marius Schilder <mschilder@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428170
Reviewed-by: Nagendra Modadugu <ngm@google.com>
There's no indication that the h/w AES function fails,
but checking the return value prevents applications
from silently proceeding and failing at a future time
(e.g. NVMEM encryption).
BRANCH=none
BUG=chrome-os-partner:55331
TEST=tpmtest.py passes
Change-Id: I8e3a9426ec31a1b0798aface55c636dc1c707b34
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/430371
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
3 minutes is too long to delay sleep after init and resume from wake
pin. This change decreases the delay to 20 seconds
BUG=none
BRANCH=none
TEST=manual
Use the cr50 power consumption to verify the sleep state
active 50mW
sleep 7mW
deep sleep 1mW
make sure suzyq is disconnected
use uart to reboot cr50
run 'reboot ap-off' on the EC console
make sure cr50 enters deep sleep at second 20
use uart to wakeup cr50 make sure it stays awake for 20 seconds
and then enters deep sleep.
wake it up again using uart and run 'idle s'
verify it enters regular sleep after 20 seconds
use uart to wake it up, make sure it does a regular sleep resume
and then goes back into regular sleep after 20 seconds
Change-Id: I65791bd3d915ceda11dc29b74e150ba589f2fa9e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/430388
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
DCRYPTO_HMAC_SHA256_init makes two calls to DCRYPTO_SHA256_init()
without an intervening HASH_final() call. This is incorrect usage
of the the hashing API, and results in the hardware SHA engine
getting locked for the life-time of the process (and resulting
in all future hash calls falling back to the software implementation).
This bug manifested itself when introducing NVRAM encryption, which
requires the hardware SHA engine to be available for key generation.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=TCG tests pass
Change-Id: Ia4ccb6a6d64636c4618ef775291442975f3f1f92
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/430154
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When debug enabled cr50 image is signed, the default manifest passed
to the signer is util/signer/ec_RW-manifest-dev.json. Images signed
with this manifest will not run on devices where the RO part is fused
for production.
It is possible to build node locked images for such devices, but the
manifest must include the lines
"DEV_ID0": <value>.
"DEV_ID1": <value>,
with the values matching the chip the image is built for.
This patch allows to pass the values in the make command line or the
environment, defined as follows:
H1_DEVIDS='<num 1> <num 2>'
When this value is defined, the default manifest is edited to add the
required lines.
One side effect of this patch is that the temp file where the edited
manifest is placed to is not deleted.
BRANCH=none
BUG=none
TEST=verified that images still can be built for both dev RW and prod
RO (node locked) with both debug features enabled and disabled
(CR50_DEV set and not set)
Change-Id: I0e81fc9aa65aa4d239e60de6047e2470f6eeaf50
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This function belongs in dcrypto as it relies heavily on the crypto
hardware; also, it will be handy to be able to use this function in
other cases.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=buildall still builds. TPM manufacturing still works too.
Change-Id: If2e70eaa71a76e8374b98f4667cb54ea6253b760
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428169
Reviewed-by: Marius Schilder <mschilder@chromium.org>
When the EC does a sysjump it redoes the PD negotiation. This changes
the voltage levels on the CC lines. Debounce the rdd disconnect signal
for 2 seconds so cr50 will ignore the negotiation and keep CCD enabled.
BUG=chrome-os-partner:60924
BRANCH=none
TEST=connect suzyq. Make sure usb does not drop out during a EC sysjump
or reboot.
Change-Id: I95b9bc81f736e3b7a65103817c140874b1ed34ec
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/426398
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Detachable devices need firmware help to process battery disconnect
requests promptly.
The request happens when the user keeps pressed both power and "volume
up" buttons and yanks the charger cable.
Once this condition is detected a 5 s timeout is started, and if the
charger cable is not plugged back in during this interval, the code
initiates a low polarity pulse on both EC_RST_L and BAT_EN outputs.
Lowering BAT_EN level will cause the battery cut off which is supposed
to cause an immediate system power down.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=verified desired behavior on an H1 dev board with a H1B2-D chip.
Change-Id: Iecdcc93e228f4bc18734569bd896b0afa4bb752a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/426345
Reviewed-by: Marius Schilder <mschilder@chromium.org>
There are three different H1 B2 chips SKUs in the wild now, one
version is for clamshell Chromebooks, one is for experimental build of
Poppy and one for detachable devices.
The SKUs differ by some fuse settings, as outlined by the comment in
the code.
This patch maps fuse settings into the chip revision string and also
makes sure that the revision is determined once and then used for all
following invocations of system_get_chip_revision().
BRANCH=none
BUG=chrome-os-partner:59833
TEST=verified that on dev boards with three different H1 B2 SKUs the
revision is reported as expected (B2-C, B2-D and B2-P).
Change-Id: I7d588d7326c28e9fa4921351254ad60a21c3f6b8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/426344
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Carl Hamilton <carlh@chromium.org>
Callers may not need computation of the public key.
Making this optional speeds this routine up.
Cr50 never passes in NULL for any argument, so is not affected.
BUG=none
TEST=build
BRANCH=none
Change-Id: Ia0077a35064f53b53f51867254aaa51eac6c55d8
Reviewed-on: https://chromium-review.googlesource.com/427058
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
With expanding USB interface to processing vendor commands and to
query current version running on the chip, there are now occurrences
of fw_upgrade_complete() invoked at the device startup without actual
data transfer.
This causes clearing rollback counter before it is actually examined.
Let's not invoke fw_upgrade_complete() unless there was actual data
transferred for flash programming.
BRANCH=none
BUG=none
TEST=verified on chromebook reboots that the counter value is not
changed until the rollback condition is checked.
Change-Id: I50bf450882b001ba1c2f38657d27f87f8596b3e2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422454
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Perform PKCS1-padding-only signing for RSASSA if hashing algorithm is
TPM_ALG_NULL.
This feature is guarded by SUPPORT_PADDING_ONLY_RSASSA macro in
tpm2/Implementation.h.
BUG=chrome-os-partner:60967
BRANCH=none
TEST=On a unowned machine with TPM2: corp enroll, login, install
a network certificate (gECC or GMC), then:
a) retrieve the public key from the installed certificate
LIBCHAPS=`ls /usr/lib**/libchaps.so`
CERTID=`pkcs11-tool --module=$LIBCHAPS --slot=1 --type=cert \
-O | grep "ID:" | awk '{print $2}'`
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID \
--type=cert -r > /tmp/cert
openssl x509 -inform der -pubkey -noout -in /tmp/cert > /tmp/pub.key
b) sign a sample text using the private key for the certificate and
MD5-RSA-PKCS mechanism, not supported by TPM2_Sign command:
echo "ABCDEF" > /tmp/1.txt
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID --sign \
-i /tmp/1.txt -o /tmp/1.sig -m MD5-RSA-PKCS
c) verify signature:
openssl dgst -md5 -verify /tmp/pub.key \
-signature /tmp/1.sig /tmp/1.txt
Step (b) should succeed and step (c) should return "Verified OK".
Change-Id: I0d7a11c48cdb04e37748f7255b98e9e023481a96
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420854
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Provide the calling stubs for p256 sign, verify, point mul, etc.
This also drops third_party/cryptoc/p256_ec and p256_ecdsa from the
image. And fewer routines from cryptoc/p256.c remain as well.
BRANCH=none
BUG=none
TEST=tcg_tests pass, test/tpm_test/tpmtest.py pass
Change-Id: Ib6c35f5d34a2c8434e78b44cbef8b69802734c50
Signed-off-by: Marius Schilder <mschilder@google.com>
Reviewed-on: https://chromium-review.googlesource.com/422942
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
After every reboot, we were resetting the write protect and console
lock states back to default. With this change the wp and lock states
will be preserved through deep sleep. They will still be reset on any
other type of reboot (like Power On reset or panic).
The states are also cleared if the system detects a rollback even when
booting from the deep sleep.
With this patch it is going to be impossible to remove hardware write
protection guarding writes into AP and EC firmware flash, unless the
cr50 console is unlocked.
Locking the console would reinstate hardware write protection
automatically even if it was disabled when the console was unlocked.
Two long life scratch register 1 bits are used to keep the console and
write protect states over resets. To make code cleaner bitmap
assignments of the long life scratch register is put in its own
include file.
BUG=chrome-os-partner:58961
BRANCH=none
TEST=manual
On prod/dev images verify that the default wp and console lock
states are still correct.
change the lock and write protect states from the default and
verify they are preserved through deep sleep.
reboot cr50 and make sure that they are reset.
unlock the console and enable flash writes, then set fallback
counter on cr50 to the value of 6 (rw 0x40000128 1; rw
0x4000012c 6) and put the AP into deep sleep by hitting
Alt-H-VolUp.
In five minutes press the power button on the device to bring
it back from s5. Observe cr50 fall back to an older image and
console lock and wp disabled.
Change-Id: Ie7e62cb0b2eda49b04a592ee1d0903e83246b045
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are plans to extend use of the LONG_LIFE_SCRATCH1 register for
other purposes than keeping board properties. Just as the board
properties, the new use is also very board specific. This patch moves
the board properties code from chip/g to board/cr50, where it belongs.
Instead of reading board properties bitmap and checking if various
bits are set, api functions are now provided to allow determining
various properties settings without actually looking at the properties
bitmap.
CQ-DEPEND=CL:*313057
BRANCH=none
BUG=chrome-os-partner:58961
TEST=verified that both Gru and Reef boot with the new image,
additionally, on Reef confirmed that it is possible to
communicate with the H1 over USB, and that plt_reset signal is
handled properly.
Change-Id: Id0dd2dc16389f773a149fb01eee1ce7bb99c4547
Reviewed-on: https://chromium-review.googlesource.com/422081
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The idle task on g devices seems to be very close to its stack
capacity. Adding debug code, print statements, etc., causes occasional
stack overflow panics.
Let's increase the stack size to avoid these problems.
BRANCH=none
BUG=none
TEST=the stack overflow panics do not happen anymore when debug
processing on the idle task context is added.
Change-Id: Id259719c1b644e2743f3bb3dbf0d99d667662901
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422078
Reviewed-by: Randall Spangler <rspangler@chromium.org>
word_in_value shouldn't be able to be used without being initialized,
so just initialize it to make GCC 5.3 happy. It's configured separately
in the (last_write_pointer & 3) and (!(last_write_pointer & 3)) paths,
so it can't actually slip through uninitialized.
There is probably a way to rwrite this that won't confuse GCC as much,
but I haven't found it yet. The solutions I did try generally ended
up increasing the binary size, so I'm falling back to just initializing
the variable.
chip/g/i2cs.c: In function '_i2cs_write_complete_int':
chip/g/i2cs.c:178:19: error: 'word_in_value' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3 and 6.2
Change-Id: Iaf8641b3d252c494ad13fbeb8ad8ece3cdfe6e76
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403504
Reviewed-by: Shawn N <shawnn@chromium.org>
Avoid building and including crypto test code in
prod builds: only define CRYPTO_TEST_SETUP when
CR50_DEV is defined.
At HEAD, this change drops the size of prod ec.RW.bin
from 200704 to 188416.
BRANCH=none
BUG=chrome-os-partner:54104
TEST=build succeeds
Change-Id: I1e6018ec917dbe71cb445206ce232b8ea7a46cb1
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/418489
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
This change adds the plumbing for SHA-384 & 512.
The actual hash implementation is software only,
and a part of the third_party/cryptoc library.
BRANCH=none
BUG=none
CQ-DEPEND=CL:418263
TEST=TCG tests pass
Change-Id: Iba7e6d420fd7fa0bce4ad9061e00f9275ecf4d72
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/417888
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
It turns out that even when the UART status register returns TX_IDLE
bit set, the transmitter is still active - probably working out the
stop sequence.
So, resetting immediately after TX_EMPTY is asserted causes the last
character to be corrupted on the receiving side.
This patch adds a wait for the duration of transmitting 10 bits at
115200 baud, which should be plenty. Wait loop in capped in case timer
is not running for any reason.
BRANCH=none
BUG=chrome-os-partner:60321
TEST=added code to print out a string and then call cflush() and reset
immediately. The last character is not lost any more, the exact
string is printed.
Change-Id: If386c515d9d9cc63d161fba73e6ed4e70e465136
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418487
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Deep sleep needs to be considered a normal behavior and should not add
to the rollback count. This change subtracts one from the reset count
when the system sees that it just resumed from deep sleep.
Ideally the rollback counter would be able to verify the TPM
functionality and detect rolling reboots. With this change the rollback
counter will only be able to detect rolling reboots, but it fixes the
false positives for rolling reboots we were seeing before.
BUG=chrome-os-partner:60449
BRANCH=none
TEST=manual
check the reset counter
turn off the AP
wait for cr50 to enter deep sleep
plug in suzyq
check it resumes from deep sleep and that the reset counter
still has the same value
Change-Id: Ie8490c29636403b409b2a3f0912a5b312d23bc24
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418321
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change adds a usb clock enable before trying to write to the usb
registers when preparing for deep sleep.
It is possible that usb has not been initialized, so we need to make
sure that the clock is enabled.
BUG=chrome-os-partner:60555
BRANCH=none
TEST=manual, on both dev and prod fused H1
run hibernate on the EC
wait until cr50 enters deep sleep
plug/unplug the charger
verify the AP can boot to the kernel
Change-Id: I26359f4224cd25dc57c32d1508e26b133c43d317
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417771
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* Include trng.h from trng.c before any other header to verify that the
header is self-contained.
* Add inclusion of stdint.h to trng.h to provide definition for uint32_t.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I78fb6d915c357236ca0fed2a57f093f0eec07fe9
Reviewed-on: https://chromium-review.googlesource.com/417424
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Set the default idle action based on whether bus obfuscation is enabled.
BUG=none
BRANCH=none
TEST=verify the idle default is sleep on b1 boards and wfi on b2.
Verify that both types of chips go to sleep and resume
successfully.
Change-Id: Ib5a11c4060aa411ff36c06c7fcadf0bf4c223bf1
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410167
