Automated code scanner highlighted a few problems in the recent ode
additions. This patch fixes the problems.
BRANCH=cr50
BUG=none
TEST=none
Change-Id: I1f199eb5d2af992384ab04f3010b4b646464a70f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897993
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When user is trying to execute 'ccd open' or 'ccd unlock' and password
is set, the return error code does not allow to tell the reason for
the command failure.
Let's add a distinct return code to indicate this condition so that
the user can supply password.
BRANCH=cr50
BUG=b:62537474
TEST=verified along with the accompanying gsctool modifications.
Change-Id: I286f87ab12114cd7dd7ebcdf0e321f7a24723367
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861208
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When TPM is wiped out on 'ccd open', the TPM reset could be invoked on
the TPM task context, if physical presence verification was not
required, or on the hooks task context, if PP was required.
This patch makes sure that the proper TPM reset is invoked depending
on the context. Also fixing the return value in ccd_command_wrapper(),
because it is expected to be from the ec_error_list enun, and this is
what is returned in the vendor command error response payload.
BRANCH=cr50
BUG=b:62537474
TEST=verified that TPM and device reset happen smoothly in both cases
when 'ccd open' requires and does not require PP.
Change-Id: I1935fc90b386bb8f2158001e153da371fca22d03
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861206
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When implementing 'ccd open' and 'ccd unlock' through gsctool, we need
to be able to pass to the host the state of the physical presences
state machine regarding the expected user action (pressing the PP
button).
Two new VENDOR_CC_CCD subcommands are being added: CCDV_PP_POLL_OPEN
and CCDV_PP_UNLOCK. In response to these commands, the Cr50 always
returns VENDOR_RC_SUCCESS return code and a single byte payload
showing the CCD and PP state:
- CCDPP_CLOSED - PP process is not running, CCD closed. Maybe user
missed a button press deadline.
- CCDPP_AWAITING_PRESS (self explanatory)
- CCDPP_BETWEEN_PRESSES (self explanatory)
- CCDPP_PP_DONE - CCD is opened/unlocked (as per user request), PP
process succeeded.
BRANCH=cr50
BUG=b:62537474
TEST=with the upcoming change to gsctool verified that PP states are
properly conveyed to the user.
Change-Id: I97b1fef4440eea93c5c5ac01b7c60bfce9a4595c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861001
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Depending on device configuration and compile time options, CCD
commands 'open' and 'unlock' could either be executed immediately, or
require the user to take the device through physical presence state
machine.
As these commands execute through TPM vendor commands, there needs to
be a different return value indicating that the command action is not
finished and PP process is in progress.
Let's add another vendor command return value, and do not consider it
a failure if vendor command returns this value in response to 'ccd
open' or 'ccd unlock'.
BRANCH=cr50
BUG=b:62537474
TEST=took an Eve through 'ccd open' sequence
Change-Id: Ie62ccfb4319a13b6fb6c1c854a0ea26beb9f517c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860999
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want to be able to tell between cases when a CCD command executed
on the TPM vendor command context was invoked through CLI or received
over /dev/tpm0.
Let's add a flag set for the duration of execution of the CLI command.
BRANCH=cr50
BUG=b:62537474
TEST=none, this is not used yet.
Change-Id: I309b4364285816a5f54522b00c93a4bf5025e2c4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860913
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Using and extending the existing framework, move ccd commands
'password, lock, open, and unlock to the same processing path.
The first three commands accept a single parameter, password. It is
required for the password command and optional for unlock and open.
The lock command does not require any parameters.
Wiping the TPM, if necessary, now happens on the same context where
CCD command is executed, i.e. the TPM task context. This is why the
same context TPM reset function needs to be exported and used here.
ccd_open() and ccd_unlock() could be further refactored, this would
require a bit more effort to find appropriate balance between
commonalities and differences.
BRANCH=cr50
BUG=b:62537474
TEST=verified that ccd commands to open, unlock, lock and set and
clear password all work.
Change-Id: I2b9f2b550347b590a55bfaef262a4f050d3f4c1c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/854709
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently only 'ccd password' command is processed using TPM vendor
command. More CCD commands are going to be processed the same way.
This patch refactors the code to make it easier to add more
subcommands.
BRANCH=cr50
BUG=b:62537474
TEST=verified that 'ccd password' still works both from crosh and CLI.
Change-Id: Id55da51d6edc5652591ad30160a4102b3026a186
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/854708
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want CCD commands lock, open, password, and unlock (at least to
start with) to be available over both CLI and through crosh (i.e.
coming over /dev/tpm0).
Let's allocate a TPM vendor command for handling all CCD subcommands,
and move to this new framework the 'ccd password' command, which
already is available over vendor command.
BRANCH=cr50
BUG=b:62537474
TEST=verified that 'ccd password' still works both over Suzy-Q CLI and
using gsctool on the target.
Change-Id: I2d06230b762f47af7e580b188a587bc5678ca169
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/853280
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Setting password should be allowed only after the owner logged in for
the first time and before they log out or someone else logs in.
Once any other user but the owner logs in, it should become impossible
to set password until the device is reset.
As proposed here, this would apply to both attempts to set password
through crosh and Cr50 console.
Password handling on Cr50 passes the following states:
- password setting is not allowed after Cr50 reset until an upstart
(as opposed to resume) TPM startup happens, as signalled by the TPM
callback. After the proper TPM reset the state changes to
'POST_RESET_STATE' which means that the device was just
reset/rebooted (not resumed) and no user logged in yet.
- if the owner logs in in this state, the state changes to
'PASSWORD_ALLOWED_STATE'. The owner can open crosh session and set
the password.
- when the owner logs out or any user but the owner logs in, the state
changes to PASSWORD_NOT_ALLOWED_STATE and does not change until TPM
is reset. This makes sure that password can be set only by the owner
and only before anybody else logged in.
Separate changes to the TPM library code make sure that TPM reset is
reported through the platform layer, so that POST_RESET_STATE is
entered.
BRANCH=cr50
BUG=b:67007578
TEST=with the rest of the infrastructure in place verified that
password can be set only when the owner logged in for the first
time before anybody else logs in or the owner logs out.
Change-Id: Ieaa3dc8ff9d2e43ae11151eb31173220f5c75b58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/804141
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Let's not allow the user to clear or change CCD password without
specifying the old password.
To keep things simple, two changes are being made:
- do not allow setting password if password is already set
- when clearing the password require user to enter
'clear:<password>' instead of just 'clear'
BRANCH=cr50
BUG=b:70029808
TEST=verified that setting password is possible only if there is no
password set currently, and that invoking 'ccd password
clear:<old password>' indeed clears the password.
Change-Id: I3753c2701e224ef89b25ad68c1b47b54eef9cdb1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/813098
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The new vendor command takes the CCD state machine through necessary
transitions leaving it in the CCD locked state.
It succeeds only if user password is not set and CCD capabilities are
right, which is guaranteed to be the case after an RMA unlock.
BRANCH=cr50
BUG=b:68213540
TEST=tested using the modified gsctool utility.
Change-Id: Ic2cce34e74b1ff476841cfa1a99f50d6a947c315
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/784352
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It is necessary to be able to set password both from the Cr50 console
and through a vendor command.
This patch moves all password management logic to the TPM task context
using the alternative vendor command path.
BRANCH=cr50
BUG=b:62537474
TEST=verified that using Cr50 console CCD password still can be set
and cleared as before.
Change-Id: I0574caf931e3717567fdb270e406643eac47764b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740914
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When RMA process has been initialized and the user entered the
expected authentication code value, the Cr50 needs to wipe out TPM
memory, open and unlock CCD and reboot the device.
This patch adds a function to accomplish that. User response is
validated on the TPM task context, and TPM reset request also requires
TPM task processing. To decouple response processing from the
following reset, the response processing is handled by a hook task
callback, delayed for 1s to make sure that user receives the response.
After TPM has successfully reset the CCD is reinitialized with RMA
'opened' and the device is rebooted.
Just in case something goes wrong with the unlock and the hook is not
invoked, add a 10s deferred function to take the EC out of reset so
that the device still can reboot.
BRANCH=none
BUG=b:67007905
TEST=on a Bob device:
- on the Cr50 console enter 'ccd lock', verify that ccd is locked
(by examining output of the 'ccd' command)
- at the bash prompt enter gsctool -r -s -t, copy the
authentication code from the Cr50 console and pass it to gsctool.
- observe the device reset TPM wiping out its memory, enable CCD
and reboot.
Change-Id: I6fafb5e642cb2b6f2040507a7f1989607fd31316
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729983
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Minor cleanup to the 'ccd help' command.
Add 'ccd get' as a clearer alias to print the config.
Change CONFIG_CMD_CCDDISABLE to CONFIG_CMD_CCD_DISABLE to indicate
that it's a sub-command for 'ccd'.
BUG=b:65407395
BRANCH=cr50
TEST=manual
ccd -> see clue for 'ccd help'
ccd help -> see 'get' command
ccd get -> prints config
ccd disable -> error (config option isn't defined by default)
Change-Id: Icbcaa178171ca948cfaae58ab1a1e73ab3d95243
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/654380
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
For historical reasons, CCD, reset, and power button control were
scattered around several files. Consolidate the code in more sensible
(in retrospect) places.
No functional changes, just moving code.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50
Change-Id: Ic381a5a5d0627753cc771189aa377e88b81b155e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653766
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Somewhere this lost a call to ccd_save_config(). Put that back.
Also, make it so 'ccd testlab' prints the current state.
BUG=b:65407184
BRANCH=cr50
TEST=manual with CR50_DEV=1 image
ccd oops
ccd testlab -> disabled
ccd testlab enable
ppresence (or tap power button)
ppresence
ppresence
ccd testlab -> enabled
reboot
ccd testlab -> enabled
ccd lock
ccd -> state=locked
ccd testlab open
ccd -> state=opened
ccd testlab disable
ppresence (or tap power button)
ppresence
ppresence
ccd testlab -> disabled
reboot
ccd testlab -> disabled
ccd testlab open -> acces denied
Change-Id: Iffdd84e8e0df3222b8762638b8a613f146c15f13
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653765
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Previously, all CCD config commands were their own distinct commands.
This led to accidental side-effects when someone would type 'ccdlock'
thinking it would print the lock state when it would actually lock the
device.
Make them all sub-commands of 'ccd'. So, 'ccd lock', not 'ccdlock'.
Just 'ccd' by itself will print the current config.
No changes to how the sub-commands themselves work.
BUG=b:65407395
BRANCH=cr50
TEST=manual with CR50_DEV=1 build
gpioget # make sure GPIO_BATT_PRES_L=0
ccd help # prints help
ccd lock # lock, because CR50_DEV=1 builds start unlocked
ccd # locked, flags=0, all capabilities default
ccd pass # access denied (we're locked)
ccd reset # access denied
ccd set flashap always # access denied
ccd unlock
ccd # unlocked
ccd pass foo
ccd # flags=2 (password set when unlocked)
ccd set flashap always # access denied
ccd set uartectx unlesslocked
ccd # yes, uartectx permission changed
ccd lock
ccd unlock # fails without password
ccd unlock bar # wrong password
ccd unlock foo # busy
(wait 3 sec)
ccd unlock foo
ccd reset
ccd # no password, flags 0, capabilities all default
ccd open # requires physical presence; tap power or use 'pp'
ccd set uartgsctxecrx unlesslocked
ccd set batterybypasspp ifopened
ccd pass baz
ccd # password set, flag 0, ccdset changes worked
ccd unlock
ccd reset
ccd # uartgsctxecrx back to ifopened, password still set
ccd open baz # still requires physical presence
ccd set opennolongpp always
ccd lock
ccd open baz # no pp required
ccd set unlocknoshortpp unlesslocked
ccd lock
ccd open baz # short pp sequence required (3 taps)
ccd lock
ccd unlock baz # short pp sequence required
ccd open baz # pp not required
ccd set unlocknoshortpp always
ccd lock
ccd testlab open # access denied
ccd testlab enable # access denied
ccd unlock baz
ccd testlab open # access denied
ccd testlab enable # access denied
ccd open baz
ccd testlab enable # requires short pp
ccd # flags 1
ccd reset
ccd # no password, flags=1, caps all default
ccd lock
ccd testlab open
ccd # opened
ccd testlab disable # requires short pp; let it time out
ccd # still opened, flags=1
ccd lock
ccd oops # backdoor in CR50_DEV images to force-reset CCD
ccd # opened, flags=0, all defaults (yes, oops wipes out testlab)
ccd reset rma
ccd # flags = 0x400000, everything but GscFullConsole always
ccd reset # back to flags=0, all default
Change-Id: Ib2905cb7cbeb79a7f4d0fb44151bfd53af361e2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653719
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, the Cr50 state machines (EC, AP, RDD, bitbang, etc.) manage
their own enabling and disabling of the ports (UART, SPI, etc.) This
is tricky because the rules for when ports should be enabled are
non-trivial and must be applied in the correct order. In additionl
the changes all need to be serialized, so that the hardware ends up in
the correct state even if multiple state machines are changing
simultaneously.
Consolidate all of that into chip/g/rdd.c. The debug command for it
is now 'ccdstate', which just prints the state machines. This will
allow subsequent renaming of the 'ccdopen', etc. commands to 'ccd
open', etc.
Also include UART bit-banging into that state which must be
consistent. Previously, it was possible for bit-banging to leave UART
TX connected, instead of returning it to the previous state.
Use better names for CCD config fields for UART. I'd had them backwards.
BUG=b:62537474
BRANCH=cr50
TEST=manual, with a CR50_DEV=1 image
1) No servo or CCD
Pull SERVO_DETECT low (disconnected)
Pull CCD_MODE_L high (disabled)
Pull EC_DETECT and AP_DETECT high (on)
Reboot. RX is enabled even if cables are disconnected so we buffer.
ccdstate -> UARTAP UARTEC
Pull EC_DETECT low.
ccdstate -> UARTAP
Pull EC_DETECT high and AP_DETECT low.
ccdstate -> UARTEC
Pull AP_DETECT high.
ccdstate -> UARTAP UARTEC
2) Servo only still allows UART RX
Pull SERVO_DETECT high (connected).
ccdstate -> UARTAP UARTEC
3) Both servo and CCD prioritizes servo.
Pull CCD_MODE_L low (enabled).
ccdstate -> UARTAP UARTEC
Reboot, to make sure servo wins at boot time.
ccdstate -> UARTAP UARTEC
Bit-banging doesn't work when servo is connected.
bitbang 2 9600 even -> superseded by servo
bitbang -> disabled
ccdstate -> UARTAP UARTEC
4) CCD only allows more ports and remembers we wanted to bit-bang
Pull SERVO_DETECT low.
ccdstate --> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI
Reboot and see we don't take over servo ports until we're
sure servo isn't present.
ccdstate --> UARTAP UARTEC (for first second)
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI (after that)
5) Bit-banging takes over ECTX
bitbang 2 9600 even
bitbang -> baud rate 9600, parity even
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
6) Permissions work. Allow easy access to full console and ccdopen:
ccdset OpenNoTPMWipe always
ccdset OpenNoLongPP always
ccdset GscFullConsole always
Default when locked is full AP UART EC RO, no I2C or SPI
ccdlock
ccdstate -> UARTAP+TX UARTEC
No EC transmit permission means no bit-banging
bitbang 2 9600 even
bitbang -> disabled
ccdstate -> UARTAP+TX UARTEC
But it remembers that we wanted to
ccdopen
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
Try turning on/off permissions
ccdset UartGscTxECRx always
ccdlock
ccdstate -> UARTAP+TX UARTEC+TX
No read means no write either
ccdset UartGscRxECTx ifopened
ccdlock
ccdstate -> UARTAP+TX
ccdopen
ccdset UartGscRXAPTx ifopened
ccdlock
ccdstate -> (nothing)
Check AP transmit permissions too
ccdopen
ccdset UartGscRxAPTx always
ccdset UartGscTxAPRx ifopened
ccdlock
ccdstate -> UARTAP
Check I2C
ccdopen
ccdset I2C always
ccdlock
ccdstate -> UARTAP I2C
SPI port is enabled if either EC or AP flash is allowed
ccdopen
ccdset flashap always
ccdlock
ccdstate -> UARTAP I2C SPI
ccdopen
ccdset flashec always
ccdset flashap ifopened
ccdlock
ccdstate -> UARTAP I2C SPI
Back to defaults
ccdoops
Change-Id: I641f7ab2354570812e3fb37b470de32e5bd10db7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615928
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This way, when HOOK_CCD_CHANGE triggers, the debug message is printed
before any of the effects of the change due to other hooks.
No effect on the rest of the code.
BUG=none
BRANCH=cr50
TEST=manual in CR50_DEV=1 image
ccdlock
ccdoops
"CCD change hook called" should be seen before "Enabling I2C" or
"Disabling I2C" messages.
Change-Id: I2e083b70fe8ac3938abc56e14b5e50fe9e237752
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616179
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Add usb_i2c_board_is_enabled().
On Cr50, this is now also connected to the I2C CCD capability. The
USB-I2C bridge can only be used when the capability is available.
On other platforms (Servo V4, etc.) where usb_i2c_board_enable() is
a no-op, add a dummy implementation which always returns true.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1
Connect host PC to dev board USB port
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
dut-control pp3300_ec_shv_reg --> fail, error 0x8001
ccdoops --> reset I2C config
ccd i2c disable --> I2C disabled
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
dut-control pp3300_ec_shv_reg --> fail, error 0x0006
ccd i2c enable --> I2C enabled
ccdunlock --> I2C disabled
ccdoops --> I2C enabled
ccdset i2c unlesslocked
ccdlock --> I2C disabled
ccdunlock --> I2C enabled
Change-Id: Ia3df32e239a5f7c5915bc6c7e408ce0dc8b26c89
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590577
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
If there is a board ID mismatch and rollback is not possible Cr50
firmware will enter a limited mode which only support Cr50 firmware
upgrade. All other features must be disabled, because it is not
possible to know which features should be allowed on the mismatched
board.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1 build, define CONFIG_CMD_CCDDISABLE
ccdinfo --> state=opened
ccddisable --> state=locked(disabled), all capabilities disabled
ccdunlock --> access denied
ccdopen --> access denied
ccdreset --> access denied
ccdpassword --> access denied
ccdset --> access denied
ccdoops
ccdinfo --> state=opened, back to defaults
Change-Id: Idb66fb1f3d5106aa0c2cb6addf2404ea9942b0d6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590070
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Define two bits in a long-life register to hold the current CCD state
across deep sleep. Update the bits on CCD config change, and restore
them on init.
This is necessary because Cr50 loses RAM contents on deep sleep. It
would be really inconvenient to open CCD, get a cup of coffee, and
come back to find CCD has locked again because Cr50 was idle too long.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1 build
ccdinfo --> state=opened
idle d
ccdunlock
ccdinfo --> state=unlocked
(wait for deep sleep)
sysinfo --> reset flags = hibernate wake-pin
ccdinfo --> state=unlocked
reboot
sysinfo --> reset flags = hard
ccdinfo --> state=opened
Change-Id: I7864f374af5c159bc9691b094958fb030f3cb8ad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/575996
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This adds the CCD configuration module, and the console commands to
control it. It is not wired up to any of the CCD capabilities; that's
coming in the next CL.
Briefly:
* CCD configuration is persistently stored in nvmem_vars. Use ccdinfo to
print it.
* CCD can be Locked, Unlocked (some capabilities), or Opened
(all capabilities), using the ccdlock / ccdunlock / ccdopen commands.
* CCD config can be restricted by setting a password via ccdpass.
* Individual config capabilities can be set via ccdset. Some of those will
be used to gate access to things like write protect and UARTs. Others
affect the requirements for ccdunlock / ccdopen (for example, is physical
presenc required).
* The entire config can be reset via ccdreset. If only unlocked, config
that is restricted to Opened is not reset.
* If CR50_DEV=1, ccdoops will force-reset and open the config.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=none
TEST=manual with CR50_DEV=1 build
gpioget # make sure GPIO_BATT_PRES_L=0
ccdlock # lock, because CR50_DEV=1 builds start unlocked
ccdinfo # locked, flags=0, all capabilities default
ccdpass # access denied (we're locked)
ccdreset # access denied
ccdset flashap always # access denied
ccdunlock
ccdinfo # unlocked
ccdpass foo
ccdinfo # flags=2 (password set when unlocked)
ccdset flashap always # access denied
ccdset uartectx unlesslocked
ccdinfo # yes, uartectx permission changed
ccdlock
ccdunlock # fails without password
ccdunlock bar # wrong password
ccdunlock foo # busy
(wait 3 sec)
ccdunlock foo
ccdreset
ccdinfo # no password, flags 0, capabilities all default
ccdopen # requires physical presence; tap power or use 'pp'
ccdset uartectx unlesslocked
ccdset batterybypasspp ifopened
ccdpass baz
ccdinfo # password set, flag 0, ccdset changes worked
ccdunlock
ccdreset
ccdinfo # uartectx back to ifopened, password still set
ccdopen baz # still requires physical presence
ccdset opennolongpp always
ccdlock
ccdopen baz # no pp required
ccdset unlocknoshortpp unlesslocked
ccdlock
ccdopen baz # short pp sequence required (3 taps)
ccdlock
ccdunlock baz # short pp sequence required
ccdopen baz # pp not required
ccdset unlocknoshortpp always
ccdlock
testlab open # access denied
testlab enable # access denied
ccdunlock baz
testlab open # access denied
testlab enable # access denied
ccdopen baz
testlab enable # requires short pp
ccdinfo # flags 1
ccdreset
ccdinfo # no password, flags=1, caps all default
ccdlock
testlab open
ccdinfo # opened
testlab disable # requires short pp; let it time out
ccdinfo # still opened, flags=1
ccdlock
ccdoops # backdoor in CR50_DEV images to force-reset CCD
ccdinfo # opened, flags=0, all defaults (yes, oops wipes out testlab)
ccdreset rma
ccdinfo # flags = 0x400000, everything but Cr50FullConsole always
ccdreset # back to flags=0, all default
Change-Id: I24e8d8f361874671e6e94f27492ae00db919bea9
Reviewed-on: https://chromium-review.googlesource.com/569439
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
