summaryrefslogtreecommitdiff
path: root/common/nvmem.c
Commit message (Collapse)AuthorAgeFilesLines
* Modify ec_comm command to corrupt NVMEM copy of kernel secdataNamyoon Woo2020-03-311-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'ec_comm corrupt' used to corrupt a copy of EC-RW hash in ec_efs.c for test purpose. This patch makes it corrupt the copy stored in the TPM NVMEM cache first, and then read it into the cache in ec_efs.c. 'corrupt' option is available for regular image as well onl if CCD is opened. 'reload' option is obsolete. BUG=b:150650877 TEST=checked the behavior in the sequence below: 0. program regular image cr50> ec_comm corrupt CCD is not opened Access Denied Usage: ec_comm [corrupt] 1. open ccd. 2. Checked the original hash code. cr50> ec_comm ... ec_hash_sec_data : /* original hash code, Hm. */ 3. Corrupt the hash code. cr50> ec_comm corrupt ... ec_hash_sec_data : /* corrupted hash code, Hc. */ 4. Reboot EC. ec> reboot ap-off 5. Check the boot mode is NO_BOOT mode. chroot$ gsctool --getbootmode ... Boot mode = 0x01: NO_BOOT 6. Turn on AP by tapping the power button. Check AP rewrites the secdata, and Cr50 reloads it. cr50> ec_comm ... ec_hash_sec_data : /* original hash code, Hm. */ Signed-off-by: Namyoon Woo <namyoon@google.com> Change-Id: Id34239911da204e1eacd285fa601a9b5db03c4ee Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2119130 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> Commit-Queue: Namyoon Woo <namyoon@chromium.org> Tested-by: Namyoon Woo <namyoon@chromium.org>
* nvmem: do not waste time looking for legacy NVMEM spaceVadim Bendebury2019-12-131-2/+3
| | | | | | | | | | | | | | | | | | | | It takes 14.5 ms to decrypt two 12K flash spaces into SRAM, then calculate their hash to see if either one is is a valid NVMEM space. There is no need for this check when the 'other' Cr50 image is newer than {3,4}.18. BRANCH=Cr50, Cr50-mp BUG=b:132665283 TEST=with added instrumentation verified that in case the other slot is occupied by 0.0.22 image, the check takes 14.5 ms, when the other slot is occupied by 0.4.23 image the check takes 8 us. Change-Id: I0414ca3d7e90d343589a21e91319f35479632eff Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1967543 Reviewed-by: Keith Short <keithshort@chromium.org>
* printf: Fix formatting errorsEvan Green2019-10-051-1/+1
| | | | | | | | | | | | | | | | | | | This change fixes the printf formatting errors found by the compile-time prinf format checker. The errors fall into a few categories: 1. Incorrect size specifier (missing or extra l). 2. Missing or extra arguments. 3. Bad line splitting. BUG=chromium:984041 TEST=make -j buildall BRANCH=none Change-Id: I5618097a581210b9fcbfc81560dec050ae30b61c Signed-off-by: Evan Green <evgreen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1819653 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* nvmem: use CC_SYSTEM instead of CC_COMMANDMary Ruthven2019-06-181-2/+2
| | | | | | | | | | | | | | | Use CC_SYSTEM for nvmem print statments instead of CC_COMMAND, so the CC_COMMAND channel will only have command output. BUG=none BRANCH=cr50 TEST=chan 0 restricts the console, so it only prints command output. Nvmem prints are still enabled by default. Change-Id: Ief79c930416a3560f7316c0df77c73504d855070 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1656628 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: complete support of the new NVMEM structureVadim Bendebury2019-04-051-150/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch eliminates unnecessary legacy nvmem.c and nvmem_vars.c code and brings the code base to the state where the new NVMEM layout is fully functional. BRANCH=cr50, cr50-mp BUG=b:69907320, b:129710256 CQ-DEPEND=CL:1450278 TEST=the following tests pass: - test cases in ./test/nvmem.c - 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: If4bc2dd125873a79dbe0e268eb32100a8b8b352d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1496607 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: clear TPM NVMEM cache when entering Alt OSVadim Bendebury2018-12-061-5/+8
| | | | | | | | | | | | | | | | | | | | | Each time TPM is disabled for booting Alt OS, NVMEM cache needs to be wiped out, only a few NV indices need to be preserved. We also are making sure that wipeout is possible only if key ladder is disabled. CQ-DEPEND=CL:1362161 BRANCH=cr50, cr50-mp BUG=b:119221935 TEST=on a dual boot machine observed that when booting ALT OS on reboots, key ladder is disabled, but RW AP firmware rollback indices at address 0x1007 are still read properly. Alt OS resume happens pretty quickly. Change-Id: I5326937d0a36b67ac848629faeee42aadcb9e64d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1362203 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: provide DCRYPTO_ladder_is_enabled() for test and fuzz buildsVadim Bendebury2018-12-061-4/+1
| | | | | | | | | | | | | | | This function is called from common/nvmem.c, it should be available when compiling for tests, the stub could be filled up later when new tests are added. BRANCH=cr50, cr50-mp BUG=b:119221935 TEST=make buildall -j still succeeds. Change-Id: I082292818c7f2b10336c9a7c49e0a9195e25a12b Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1363816 Reviewed-by: Allen Webb <allenwebb@google.com>
* cr50: revoke key ladder on disabling TPMNamyoon Woo2018-12-051-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disabling TPM will do revoke H1 key laddder. Querying TPM_MODE or enabling TPM_MODE will fail if H1 Key Ladder is already revoked. BUG=b:118504817 BRANCH=cr50 TEST=Manually tested with TPM disabling and Resume or Warm Reboot. (1) Resume $ trunks_send --raw 80 01 00 00 00 0c 00 00 01 45 00 01 80010000000A00000000 $ gsctool -a -m disable TPM Mode: disabled (2) $ echo mem > /sys/power/state (press key on chromebook either after three seconds or in a second.) (2) Warm Reboot $ gsctool -a -m disable (press refresh + power button or run kernel command 'reboot') Check Chrome os boot ok. No TPM command failures were observed (in CR50 console). (3) Windows Warm Reboot or Resume are checked. Change-Id: I32fffc432a9a6068ea324a97225974c581cb9359 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1312197 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: Make sure TPM wipe only clears TPM data.Aseda Aboagye2017-02-231-10/+17
| | | | | | | | | | | | | | | | | | | | Previously, wiping the TPM would wipe all of NvMem, however, it really should only clear the TPM's NvMem space. This commit adds a function to clear a given NvMem user's space and makes the TPM only clear its space. BUG=chrome-os-partner:61597 BRANCH=None TEST=Add code for using nvmem vars, create a test variable, add a user to snappy, unlock the console, verify that the user is no longer present on the system and the test nvmem var still exists. TEST=make -j buildall Change-Id: Ic98baa5166a1ef9ae76e910b1b9ab100300e947f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/445803 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* nvmem: do not prefer old partition over new one.Vadim Bendebury2017-02-221-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | The code deciding which partition to choose properly determines which one is newer, but invariably populates the cache with the second one, when both partitions are valid. This is obviously wrong, on top of that there is no need to check both partitions' validity, if the newer one checks out. BRANCH=none BUG=chrome-os-partner:60555, chrome-os-partner:61972 BUG=chrome-os-partner:61716, chrome-os-partner:61234 BUG=chrome-os-partner:61167, chrome-os-partner:60555 TEST=successfully ran $ ssh 192.168.1.102 suspend_stress_test --suspend_min 10 \ --suspend_max 10 --wake_max 10 --wake_min 10 for more than 300 cycles (it still is going) Change-Id: I02d9bb062b9edbbb9787a95ba760872e09ff2761 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/445356 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org>
* commom: enable commits prior to checking for valid nvmem partitionsScott2017-02-081-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If both nvmem partitions are corrupted, then nvmem_reinitialize() will be called and commits must be enabled prior to this so that nvmem_release_cache() succeeds. BRANCH=none BUG=chrome-os-partner:62531 TEST=On Reef after a successful boot, corrupt nvmem partitions using the following console commands: flasherase 0x7d000 0x3000 flasherase 0x3d000 0x3000 Then reboot via H1 console and verified via the console that the nvmem partitions were reconfigured. nvmem_find_partition:302 partiton 0 verification FAILED nvmem_find_partition:302 partiton 1 verification FAILED [0.025928 nvmem_find_partition: No Valid Partition found, will reinitialize!] [0.127752 Active Nvmem partition set to 1] Then verfied that TPM was functional and the system booted booted into the kernel. Without this CL this set of actions would always result in going in to recovery mode due to TPM failure. Change-Id: If1691b179e19cb37f0fc6ba893219dd8c02f2cf5 Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/439368 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* common: do not release lock after nvmem read when commits are suspendedVadim Bendebury2017-02-061-2/+2
| | | | | | | | | | | | | | | | | The nvmem_release_cache() function checks if there is a pending write and refuses to release the lock if so. It should also be checking if submits have need suspended, as the task suspending commits is holding the lock and is supposed to release it explicitly when done. BRANCH=none BUG=chrome-os-partner:62531 TEST=verified that the message reporting attempts to commit when cache is unlocked is not showing up at startup any more, Change-Id: I5a63e7421cdd4a6b11dddff3103e1d63e0be0e65 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/437758 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* nvmem: do not use malloc for cached bufferVadim Bendebury2017-01-281-221/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* nvmem: encrypt contents using crypto apiVadim Bendebury2017-01-251-112/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes incompatible changes to the nvmem layout: the header is increased to accommodate a 16 byte sha ans a 16 byte padding for future extensions. The layout version field is also introduced to make it easier to track changes in the future. When calculating SHA the entire partition above the SHA field is processed. Encryption covers everything above the header. Introducing encryption makes it impossible to use flash contents directly for read and compare operations. The nvmem_setup function is modified to use the nvnem_save() instead of writing into the flash directly. BRANCH=none BUG=chrome-os-partner:62260 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: I50b148ac0dc6bc924f4d65c67bc6610100d9dfc0 Reviewed-on: https://chromium-review.googlesource.com/428691 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* g: common: introduce generic crypto APIVadim Bendebury2017-01-251-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* nvmem: rename version to generationVadim Bendebury2017-01-241-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With upcoming versioning of NVMEM contents let's replace term 'version' with term 'generation' in the existing nvmem implementation. Generation would allow to tell between two instances of NVMEM stored in flash memory. The upcoming version field in the header will be used to tell between different nvmem layouts. This patch was created by invoking the following command: sed -i 's/VERSION/GENERATION/g;s/version/generation/g' \ common/nvmem.c include/nvmem.h test/nvmem.c and then editing a few remaining capitalized instances. This also fixes nvmem test broken by an earlier patch. BRANCH=none BUG=chrome-os-partner:62260 TEST=the following tests succeed: make buildall -j TEST_LIST_HOST=nvmem make runtests booitng reef with cr50 Change-Id: I96e52dc93ca7c52c55794ba3e8c2774571212de0 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/431312 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* common: prepare nvmem for encryption supportVadim Bendebury2017-01-181-88/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch mostly is rearranging the code to make it easier to add encryption layer in the upcoming change. One substantial change is making sure that in case when NVMEM contents are corrupted for whatever reason, the initialization function re-creates a blank NVMEM space; it was just bailing out before not leaving any initialized partitions behind. There is no need in two separate tables - one for base absolute addresses of the NVMEM partitions, and one for their flash memory offsets, one can be easily derived from the other. Code erasing the destination partition, calculating the SHA1 of the new blob and writing it into the flash was separated into own function. BRANCH=none BUG=chrome-os-partner:55331 TEST=make buildall -j still passes (which means NVMEM tests succeed). TPM TCG test suite also passes. Change-Id: I378265d8b49b81398aece2eadf9698abb05caaa1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/428172 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* cr50: Avoiding nvram commits at startupVadim Bendebury2017-01-051-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch eliminates NVMEM commits at system startup, namely between the moment the TPM is reset and the moment the AP is trying to read a PCR (which is an indication of the AP having booted into OS). To avoid losing NVMEM changes in case TPM is reset before PCR Read command is issued, pending changes (if any) are saved before TPM reset is processed. For the same reason TPM reset invocation is being added to the hard reboot path; this will kick in when there is a restart after cr50 firmware update. BRANCH=none BUG=chrome-os-partner:59873 TEST=with instrumented coreboot/depthcharge observed the following execution times for various TPM command issued at startup command 0x144, 15203 us command 0x14e, 11814 us command 0x182, 12461 us command 0x182, 12456 us command 0x138, 11503 us command 0x138, 11512 us command 0x14e, 14648 us command 0x14e, 12597 us command 0x121, 11353 us which totals 113 ms and shaves more than 200 ms off the boot time. Change-Id: Ic52309291fdb9c3ede96e0ad015ad9fc076bddc5 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424063 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* nvmem: fix partition number assignment in nvmem.cVadim Bendebury2016-09-281-2/+3
| | | | | | | | | | | | | Partition number must be set before partition lock is attempted. BRANCH=none BUG=none TEST=the cert installation image does not crash on gru any more Change-Id: Ibc81e2e741fafb75f4e4bb5dbfc0dae32d354646 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/390416 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* Cr50: Clear NVMEM before unlocking the consoleBill Richardson2016-09-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | The Cr50 console provides access to all sorts of dangerous commands. To protect user secrets, we must erase the persistent storage before unlocking the console. Note that this will not powerwash the AP, leaving you with the impression that you've just forgotten your password. You'll have to manually powerwash (Ctrl+Alt+Shift+R) afterwards. That will be addressed in a future CL. BUG=chrome-os-partner:55728 BRANCH=none TEST=make buildall, test on Gru Lock the console if it's not already ("lock enable"), then unlock it with "lock disable". Confirm that the NVMEM region is erased following a successful unlock process. Change-Id: Iebcd69c9f757f5ab5d496218f065197d3f1f746c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/382666 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Cr50: NvMem: Allow for partitions to not be contiguousScott2016-09-021-21/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | TPM2.0 needs more NvMem space and currently the whole block is contiguous in memory with 2 partitions. This CL removes the requirement that the partitions are in contiguous which allows for 1 partition to placed at top of RW_A and the other at RW_B. This CL does not change the size of each partition as that will be done in a subsequent CL. BRANCH=none BUG=chrome-os-partner:56798 TEST=manual Tested with the unit test 'make runtests TEST_LIST_HOST=nvmem' and verified that all tests pass. Tested on Kevin, erased the existing NvMem area and verified that TPM was still manufactured and executed the command: trunks_client --own Erased parition 0 and 1 in the new locations and repeated the tests. Change-Id: I295441f94dccdf5a152c32603c2638ffac23f471 Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/378675 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Tested-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Cr50: NvMem: Added write/move error stateScott2016-08-111-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nvmem_write() and nvmem_move() funcitons return an error if the write or move operation would exceed the user buffer boundary. However, the TPM2 functions which call these functions do not check for errors. Instead TPM2 NvMem relies on the return value of the nv_commit() function to determine if a TPM command which modifies NvMem succeeds or fails. This CL adds a nvmem_write_error flag which is set in cases where an nvmem_write/nvmem_move returns an error. This error flag is then checked in nvmem_commit() so that the commit operation can be abandonded and the error returned back up the TPM2 stack. Tested in full system for two cases. Installed TPM certificates on the Cr50, then manually erased NvMem with flasherase 0x7b000 0x5000 and rebooted system. Then on Kevin console entered the command <trunks_client --own> NV_MEMORY_SIZE = 9932 NVMEM_TPM_SIZE = 7168 Case 1 -> Without internal write error state, so commit() always executes if called. In this case, the Kevin console reports a TRUNKS_RC_WRITE_ERROR and there is a Cr50 reboot. Kevin Console: localhost ~ # trunks_client --own [INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK. [INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK. [ 134.056217] tpm tpm0: Operation Timed out [ERROR:tpm_utility_impl.cc(1987)] DoesPersistentKeyExist: querying handles: TRUNKS_RC_WRITE_ERROR [ERROR:tpm_utility_impl.cc(269)] TakeOwnership: Error creating salting key: TRUNKS_RC_WRITE_ERROR [ERROR:trunks_client.cc(98)] Error taking ownership: TRUNKS_RC_WRITE_ERROR Cr50 Console: > [131.501920 nv_commit()] [142.494755 nv_wr: max off = 0x1250] [142.496347 nv_wr: max off = 0x17b4] [142.548296 nv_commit()] [142.678001 nv_rd: max off = 0x1250] [142.679350 nv_rd: max off = 0x1254] [143.269614 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00] [143.271460 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00] [143.273055 Wr Err = TRUE, Resetting error only, not returning] [143.325073 nv_commit()] --- UART initialized after reboot --- [Reset cause: rtc-alarm] [Image: RW_B, cr50_v1.1.5056-8e5dc99+ private-cr51:v0.0.69- 12:23:02] [0.004349 Inits done] [0.007150 Active NVram partition set to 0] [0.008086 Debug Accessory connected] [0.009076 USB PHY B] Console is enabled; type HELP for help. tpm_manufactured: manufactured [1.155766 usb_reset] [1.240155 usb_reset] [1.311188 SETAD 0x6c (108)] Case 2 -> Using internal error state to gate the commit() operation. In this case, the attempted write overflow sets the internal error state and the commit() following attempted overflow detection is not exectued. It results in a different AP TPM error shown below as Error encrypting salt. The other different behavior is that observed is that if after failing on the RSA SRK, the ECC SRK write is still attempted. Kevin Console: localhost ~ # trunks_client --own [INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK. [INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK. [ERROR:session_manager_impl.cc(154)] Error fetching salting key public info: Handle 1: TPM_RC_HANDLE [ERROR:session_manager_impl.cc(94)] Error encrypting salt: Handle 1: TPM_RC_HANDLE [ERROR:tpm_utility_impl.cc(277)] TakeOwnership: Error initializing AuthorizationSession: Handle 1: TPM_RC_HANDLE [ERROR:trunks_client.cc(98)] Error taking ownership: Handle 1: TPM_RC_HANDLE Cr50 Console: > [107.867473 nv_commit()] [133.743522 nv_wr: max off = 0x123f] [133.744908 nv_wr: max off = 0x1250] [133.746159 nv_wr: max off = 0x17b4] [133.798498 nv_commit()] [133.900131 nv_rd: max off = 0x1250] [133.901496 nv_rd: max off = 0x1254] [134.507033 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00] [134.508852 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00] [134.510440 Wr Err = TRUE, Aborting Commit!] [144.856751 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00] [144.858611 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00] [144.860198 Wr Err = TRUE, Aborting Commit!] BRANCH=none BUG=chrome-os-partner:55910 TEST=manual Test in system as described above and ran NVMEM unit tests and verified that when a write would overrun the user buffer, the write fails and sets the error state. Then, verified that the nv_commit() call returns an error and clears the internal error state. Change-Id: I376e17b273003ff3d75459b4e68ed69d42dc7415 Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/366757 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: fix nvmem calculationsVadim Bendebury2016-08-081-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nvmem space defined in the ec code base for the cr50 board is used by the TPM2 library, which has its own nvram size definition. The two definitions must match. On top of the fact that the definitions are not locked to each other, there is a third completely unrelated nvram size definition in board/cr50/board.c. This patch unifies nvmem size definitions between cr50 and tpm2 repositories by adding a compile time check for the size to be the same on both sides. Also, it turns out that two certificates (RSA and ECC) together do not quite fit into the cr50 TPM nvram. Hence the total allocated nvmem space is being increased to 20K (note that the actual nvram size available to the TPM is less than half of this). BRANCH=none BUG=chrome-os-partner:55898 TEST=tpm does not lock up any more when 'tpm_client --own' is ran on the Kevin-tpm2 command line CQ-DEPEND=CL:367010 Change-Id: I20b4f54118bd2fa12e5bd5741d6c58fbe91f65d1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/366796 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Cr50: NvMem: Modified nvmem_init to handle 2 corrupt partitionsScott2016-07-221-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | During initialization the NvMem module looks for either a valid partition or that the NvMem area is fully erased. If neither of these two conditions were found, then it was only returning an error code and logging a message to the console. This CL modifies nvmem_init() so that if the error case as described above is detected, then it will call nvmem_setup() which will create two valid partitions. In addition, the setup function erases all of the existing data in the NvMem space. Enhanced the unit test that deals with both partitions being corrupted so that it verifies the version numbers are correct and that all user buffer data is set to 0xff. BUG=chrome-os-partner:55536 BRANCH=None TEST=Manual Executed make runtests TEST_LIST_HOST=nvmem and verifed that all tests passed. Change-Id: Ib932e02f15bd1aad7811032a12d826c76476e53f Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/362448 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Cr50: NvMem: Added mutex lock protection for cache memoryScott2016-06-221-51/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added mutex lock for nvmem write/move operations. In the current implementation, there is no single entry point for the platform specific NvMem calls. The mutex lock is coupled with a task number so that the same task can attempt to grab the lock without stalling itself. In addition to the mutex lock, changed where the cache.base_ptr variable is updated. Previously, this was done prior to the partition being copied from flash to the shared memory area. Now, the variable is only updated after the copy so that read operations will always read from the correctly from either flash or from cache memory if a write operation has been started. BRANCH=none BUG=chrome-os-partner:52520 TEST=Manual make runtests TEST_LIST_HOST=nvmem and verify that all tests pass. Tested with tcg_test utility to test reads/writes using the command "build/test-tpm2/install/bin/compliance --ntpm localhost:9883 --select CPCTPM_TC2_3_33_07_01". Change-Id: Ib6f278ad889424f4df85e4a328da1f45c8d00730 Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/353026 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* nvmem: provide a function to wipe out nvmem contentsVadim Bendebury2016-05-311-1/+3
| | | | | | | | | | | | | | | | | | It is important to be able to wipe out the non-volatile memory for various reasons. This patch adds this ability for both when NV memory is kept in SRAM and in flash. Also a minor clean up to eliminate some code duplication and to have normal flow messages printed out with time stamps. BRANCH=none BUG=chrome-os-partner:44745 TEST=just makeall at this time. Change-Id: I59c1909669aeaa9e8ffb3d8ef81b02fa0facb6ab Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/348291 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Cr50: NvMem: Connected function stubs in /board/tpm2/NVMem.cScott2016-05-261-2/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Used #define CONFIG_FLASH_NVMEM to have functions in /board/tpm2/NVMem.c utlitize on chip Nvmem functions. On chip NV Memory availability is tied to an internal nvmem error state which itself only depends on finding at least one valid partition. Added nvmem_is_different and nvmem_move functions which were needed to complete the tpm2 platform interface. In addition, added unit tests to support these two new functions. BUG=chrome-os-partner:44745 BRANCH=none TEST=manual make runtests TEST_LIST_HOST=nvmem and verify that all tests pass. Tested with tcg_test utility to test reads/writes using the command "build/test-tpm2/install/bin/compliance --ntpm localhost:9883 --select CPCTPM_TC2_3_33_07_01". Change-Id: I475fdd1331e28ede00f9b674c7bee1536fa9ea48 Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/346236 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* NvMem: Added NV Memory module to ec/common/Scott2016-05-261-0/+451
Full implementation of NvMem read, write, and commit functions. Includes partition definitions, shared memory allocation, and initialization function. Includes a set of unit tests located in ec/test/nvmem.c which verify functionality. This module is required by Cr50, however this CL does not include any Cr50 specific code. BUG=chrome-os-partner:44745 BRANCH=none TEST=manual make runtests TEST_LIST_HOST=nvmem and verify that all tests pass Change-Id: I515b094f2179dbcb75dd11ab5b14434caad37edd Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/345632 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
View Lorry Controller Status