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
The original thought of setting LRESET_PLTRST_MODE to 1 is to remove the
need to reinitialize host module registers whenever LRESET# occurs in
order to save time when boot-up.
However, some of these registers will be reset by core domain reset. It
means every time LRESET is de-asserted, we need to initialize the host
setting again. Therefore, setting LRESET_PLTRST_MODE to 1 is unnecessary
and sometimes dangerous. If BIOS believes LRESET will reset ec's host
state machine to default but ec not, it will cause unexpected behavior.
Modified drivers:
1. lpc.c: allow LRESET/PLTRST generate host domain reset
BUG=chrome-os-partner:60211
BRANCH:none
TEST=make buildall. run "dut-control pwr_button:press; sleep 11; dut-control
pwr_button:release; sleep 7; dut-control pwr_button:press; sleep 1;
dut-control pwr_button:release". Verify keyboard works normally.
Change-Id: I94d428cde69f828468547c44844983f25686ea04
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/417745
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
__hw_clock_event_set() is not reentrant and may be called from both our
event timer ISR and our hwtimer ISR when hwtimer is close to wrapping.
Modify the interrupt priority of our hwtimer int to match our event
timer int so that one cannot preempt the other. Originally the priority
was changed to allow the hwtimer ISR to run first in case both are
pending, but this condition can be handled cleanly and isn't a big
concern.
BUG=chrome-os-partner:60470
BRANCH=gru
TEST=Pass 500 S/R cycles on kevin with hwtimer wrap rate sped up 300x
(roughly equivalent to 150,000 real S/R cycles).
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ied466f14661f04c8662b5db709c0e3770a5bb200
Reviewed-on: https://chromium-review.googlesource.com/417060
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit ac28ec53b63a02c4d25e8a222d13595bc857fef0)
Reviewed-on: https://chromium-review.googlesource.com/417112
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The manifest used for signing in dev mode was originally used for
kevin evt 1, but now it is a common dev mode manifest. Rename the fie
appropriately and modify the makefile using it.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=verified that it is still possible to build cr50 with CR50_DEV=1
Change-Id: If744406a83a7045cd34c76c941fdef209bef51ac
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
gru has circuitrythat selects the charge LED color based on the
frequency of the PWM.
By adjusting the PWM frequency instead of just the duty, we gain more
control over the brightness of the charge LED.
BUG=chrome-os-partner:54155
BRANCH=gru
TEST=activate each LED in turn and confirm color and brightness
Change-Id: Ie653125a528595c1ec68aea4d02cb70595a1b151
Signed-off-by: David Schneider <dnschneid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415517
Reviewed-by: Shawn N <shawnn@chromium.org>
When a WAIT is received in response to a request, wait SinkRequestTime
before resending the request.
BUG=chrome-os-partner:34984
TEST=make -j buildall
BRANCH=none
Change-Id: I5c8429c4a7b9cf06609996f924b8d9d535ab6b5f
Reviewed-on: https://chromium-review.googlesource.com/414533
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Common code is more flexible and supports more parts, so delete the
npcx-only register translation code.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on gru, run 'flashrom -p ec --wp-enable' and check that 0x28
gets written to SR1, which matches our desired 'protect botton 128KB',
according to the datasheet. Also run 'flashrom -p ec --erase' then read
back EC SPI contents, verify ROM is erased except for first 128KB
region.
Change-Id: I526401997ff7ec77f2a6047a4a9af74a671ed69a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 43634d36d273887b1f2349c333a7b4b229a83365)
Reviewed-on: https://chromium-review.googlesource.com/415498
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
If UMA is locked, read and write access to SR* regs will fail, and we'll
be unable to determine or change our write protect state. Save our SR
regs before enabling UMA lock, and bring down UMA lock for a brief
period when writing SR regs.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on kevin with SW sync enabled.
flashrom -p ec --wp-enable -> verify success, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Reboot host, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now all_now
Verify flashrom -p ec --wp-status shows protected, and flashrom -p ec
--wp-disable fails.
Also verify same state after EC reset.
Boot into recovery mode, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Remove WP screw, reboot EC, check flags:
Flags: ro_at_boot ro_now
Verify flashrom WP status shows protected, and flashrom WP disable
succeeds and clears all flags.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I17e32f7305600183e7fcb87f69a3feb88978f94e
Reviewed-on: https://chromium-review.googlesource.com/412977
(cherry picked from commit 6cfc0d0dd030b8b0334f99e99950a52fcf8267af)
Reviewed-on: https://chromium-review.googlesource.com/415497
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change adds support for signing SHA-384 & 512 hashes
when using PKCS#1 padding (CR50 does not support
SHA-384 & 512 at the moment, the actual hashing is to be
done on the host).
BRANCH=none
BUG=chrome-os-partner:59754
TEST=TCG tests pass
Change-Id: I78e774639a7968cbb50e58cdd0bf479e64123630
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/415218
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Enabling and disabling sleep in the rdd interrupt is redundant because
USB already takes care of that. When USB is initialized it will disable
sleep. If it is released or suspended then it will re-enable sleep. This
change removes the sleep enable and disable from the rdd interrupt. With
this change now sleep can be enabled while suzyq is still plugged in
using the command 'ccd disable'.
BUG=none
BRANCH=none
TEST=manual
The consoles still work
Updating the EC, AP and Cr50 still works
After running 'reboot ap-off' in the EC console and 'ccd
disable' in the Cr50 console Cr50 will go to sleep.
Change-Id: Ie8e6201e9fd611c514e93bc70d298d3b0d228611
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413606
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces version 6 of the cr50 USB update protocol. This
version allows to multiplex TPM vendor and extension commands over the
same USB endpoint which is used for firmware updates.
When channeling TPM vendor commands the USB update frame looks as follows:
4 bytes 4 bytes 4 bytes 2 bytes variable size
+-----------+--------------+---------------+-----------+------~~~-------+
+ total size| block digest | EXT_CMD | Vend. sub.| data |
+-----------+--------------+---------------+-----------+------~~~-------+
Where 'Vend. sub' is the vendor subcommand, and data field is
subcommand dependent. The target tells between update PDUs and
encapsulated vendor subcommands by looking at the EXT_CMD value - it
is set to 0xbaccd00a and as such is guaranteed not to be a valid
update PDU destination address.
In the previous protocol versions target reset was requested by the
host sending a 4 byte PDU after the target receives the UPGRADE_DONE
message and moves the state machine to the 'awaiting_reset' state.
With the ability to transfer vendor commands, there is no need for the
target to have a special state for reset. The host can send the posted
or immediate reboot request using the appropriate vendor command.
As a result the 'awaiting_reset' state has been removed, the target
accepts vendor commands only when state machine is in the rx_idle
state.
Vendor command response size is not fixed, it is subcommand dependent.
In the current implementation the total size of the vendor command PDU
can not exceed 64 bytes, as there is no reassembly on the target side.
For backwards compatibility in case the target is running protocol
version earlier than 6, the 4 byte PDU is still sent to the target
after UPGRADE_DONE is sent.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=tested updates on Reef and Gru, observed that it is possible to
update earlier versions of firmware, and that it is possible to
request immediate and posted reset (depending on the presence of
the -u flag in the usb_updater invocation).
Change-Id: I6ea9e9f742c96b8ab0670e9cec87a83cd47bb20e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When usb update errors happen it helps a lot to be able to see the
actual error code returned by the target and where the error was
generated.
This patch adds a few printouts to help with debugging.
BRANCH=none
BUG=none
TEST=observed proper error messages generated while debugging
introduction of extension/vendor commands transfer over USB.
Change-Id: I06c77e7467f7f9547704c88c4b673866fb2e6032
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414947
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some upcoming changes will introduce transfer of vendor and extension
commands over the usb updater endpoint.
This patch exposes a function which allows to verify integrity of
received USB PDUs.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=no functional changes, usb_updater still works fine.
Change-Id: I8d9e6746ef0dfbb17bba618410514ca047a59a45
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414441
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This describes a 5-finger touchpad. The physical/logical dimensions
of the trackpad are hardcoded for the time being.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: I04a0833a28c013395974104ebdd6fcb29e5d6680
Reviewed-on: https://chromium-review.googlesource.com/407742
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For example, when a HID descriptor is longer than 64 bytes, we need
to split it in multiple packets.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: I25a05eabaf9413e332fe3cd70695a0d53639713d
Reviewed-on: https://chromium-review.googlesource.com/409316
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This first cleans up the code:
- Define report as a structure.
- Fix USB interval from 40 ms to 32 ms (Linux kernel complains
otherwise).
Then, this removes the old set_keyboard_report interface, and
replaces it by the interface used by the keyboard scanner
(i.e. keyboard_state_changed and keyboard_clear_buffer).
This also means we need a keycode table to translate from
row/column to USB HID keycode.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
With evtest and "hid 0-7" in console, check that key are
reported correctly.
Change-Id: I5d526db1568c29c7f28fc5e962e213e44303cc16
Reviewed-on: https://chromium-review.googlesource.com/411571
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When cr50 rollback happens, the newer header's magic field is set to
zero to prevent it from ever running again.
Take this into consideration when displaying versions of the inactive
RW image.
BRANCH=none
BUG=none
TEST=loaded two versions of the new code on a cr50 and then modified
the fallback counter to force it to boot the older version and
reboot a Reef. Once Reef fully boots to chrome os examine CR50
version report:
Before:
> vers
...
RW_A: 0.0.9/DEV/cr50_v1.1.5654-2228b76+
RW_B: * 0.0.11/DEV/cr50_v1.1.5654-2228b76+
...
After:
> vers
...
RW_A: * 0.0.9/DEV/cr50_v1.1.5654-2228b76+
RW_B: Error
Change-Id: I2a9ee13117a0bc91710226cd733c5c484c6d0595
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413089
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The mux for selecting source clock of ITIM will introduce a delay
and have a chance to make ITIM's source clock and core clock are
asynchronous. We need consecutive reading for ITCNT32 no matter source
clock is APB2 or 32k.
Modified sources:
1. hwtimer.c: Add consecutive reading for ITCNT32
BRANCH=none
BUG=chrome-os-partner:34346,chrome-os-partner:59240
TEST=No time stamp symptoms occur on wheatley for 30 hours.
Change-Id: I8b54e93b320e3ea74fc3d6ea13f0d178f9c449cd
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/412505
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When the host requests the uploader to post a reboot request, the
uploader should exit right away once the request is posted.
BRANCH=none
BUG=chrome-os-partner:59911
TEST=verified that cr50 gets successfully updated from this image to a
newer one on both reef and gru: the reboot happens under upstart
control, not by cr50 rebooting on its own.
Change-Id: I9e4a2da686fe512b633daa05c675871e5946926f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412348
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The 'cycles' register will be clobbered by our macro, so it must be
specified as an output operand that may also be used as input.
BUG=chrome-os-partner:60000
BRANCH=gru,strago,glados
TEST=Build + burn wheatley, verify alignment exception is not
encountered on boot. Also verify produced assembly is still correct:
100a89a6: 2303 movs r3, #3
100a89a8: 3b01 subs r3, #1
100a89aa: d1fd bne.n 100a89a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I1be03a006967aed6970dbac5d98a19a31e0b7d49
Reviewed-on: https://chromium-review.googlesource.com/412441
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We always want set_keyboard_report to send the freshest possible
data. For this purpose, we use double-buffering on the USB
endpoint.
When the endpoint is currently busy, we sneak in an address change,
hoping that the hardware will pick it up. There is no guarantee
about which buffer was transferred, so we queue another transfer
anyway. This means that the code will send a duplicate (harmless)
report in that case.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: I9d14541b8b05017c1d5051b9a315db381a89dcea
Reviewed-on: https://chromium-review.googlesource.com/411741
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the future, we'd like to have different HID devices on different
endpoints (keyboard, trackpad, etc.), so we'd like to separate the
keyboard handling.
For other chip implementing usb_hid.c (namely, chip/g), we, for now
just rename the config option and endpoint/interface definitions.
Making the code more generic can be done at a later stage.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: Iad1b00fa226f7635c0f34aae6a435dc53a3ea555
Reviewed-on: https://chromium-review.googlesource.com/409256
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
block offset was being used in a printf before it was being
initialized. Initialize it earlier to fix the problem.
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: I3233ca3b10d35a6f61036c2e30224dc3747618fd
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403501
Reviewed-by: Shawn N <shawnn@chromium.org>
In the S0 <-> S3 transition, Coreboot sends EC messages to set/clear
the wake masks when the SMI is invoked. For S0ix, EC sets and clears
the wake mask via this patch.
These functions are directly invoked from the state machine transition
states. During S0ix entry, the wake mask for lid open is enabled.
During S0ix exit, the wake mask for lid open is cleared. All pending
events are also cleared.
BRANCH=none
BUG=chrome-os-partner:58740
TEST=test lidopen in S0ix
Change-Id: I398fdba2b9bba1f6caef46f8dc71c7de3b669d08
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/401070
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The `idlestats` command was not behind the CONFIG_CMD_IDLE_STATS option;
this commit fixes that.
BUG=None
BRANCH=glados
TEST=build a board that uses mec1322. Undef CONFIG_CMD_IDLE_STATS;
verify that the command isn't present in the build.
Change-Id: Id17c8377f812ee2a63dc4507766c1c557704dcb1
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/411518
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Various cryptographic operations leak timing
information if comparisons are not executed
in constant time. This change adds DCRYPTO_equals(),
a constant runtime comparator.
Also replace crypto related callsites that used
memcmp() as a binary comparator.
BUG=none
BRANCH=none
TEST=tcg tests pass
Change-Id: I3d3da3c0524c3a349d60675902d1f2d338ad455f
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/410163
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When bus obfuscation is enabled we have the chance of doing a security
reset when resuming from sleep. Since we cannot disable bus obfuscation
on current boards, we need to disable sleep.
BUG=chrome-os-partner:57994
BRANCH=none
TEST=make buildall
Change-Id: I6f49278a9b41c1d15c646838044e34f03b979479
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/409576
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If our 32-bit usec timer is close to overflow, we may deep sleep several
times in succession without making any adjustment to our count, causing
deadlines on the other side (eg. HOOK_TICK expiration) to be reached much
slower than expected. Avoid this by not entering deep sleep if our timer
is about to overflow. This will result in a <= HOOK_TICK_INTERVAL (200ms
interval) period of not entering deep sleep, every ~4300 seconds.
BUG=chrome-os-partner:59240
BRANCH=gru
TEST=Verify 3x kevin units survive 16 hours in S3 without EC watchdog.
Change-Id: I2126458be8820f78212e19c2bb79242ff1194f6f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/409673
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
- Wait for ITEN bit to be set / cleared, since writing this bit just
sets a 'request'.
- Ensure ITIM_EVENT_NO reg is set with minimum value 1, per the
datasheet.
- Don't dsleep if our wake event is in the past (eg. wake event will
occur any time now)
BUG=chrome-os-partner:59240
BRANCH=gru
TEST=Manual on kevin, verify that dsleep period never exceeds expected
wait period. Also verify that EC watchdog doesn't occur after 5 hours in
S3.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iedb2723c3f12b74dea66082b1d8b8ce1b6e7d945
Reviewed-on: https://chromium-review.googlesource.com/409672
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change is a safegaurd to ensure that TPM register data is always
placed in the correct location in the HW read I2CS fifo. It is only
checked for 1 or 4 byte regsiter reads. Because of the way in which a
TPM command is sent and the response is read, there are multiple reads
of the STS register prior to reading the TPM fifo register. Therefore
ensuring the fifo has zero depth when 1 or 4 byte regsiter reads,
improves the robustness of the design.
Added a counter to track the number of times the fifo is adjusted and
a new console command 'i2cs disp|rst' to display the count and reset
it to 0 if desired.
Removed section in code for TPM fifo register reads intended to handle
the case where there was a mismatch between how many bytes were copied
into the fifo and the number read by the host. Since the burstcount
field in the status register always contains a valid amount of data
that can be read by the host, there should not be cases where the
host reads less data than was copied from the TPM fifo register. In
the unexpected cases where the host may not drain all of the I2CS read
fifo data during a TPM register read, the I2CS fifo depth will be
corrected the next time that it reads either the access or STS
register which happens prior to the start of any TPM transaction.
BRANCH=none
BUG=chrome-os-partner:57338,chrome-os-partner:59191
TEST=manual
Booted Reef and verfied that TPM functionality is working.
Change-Id: I065a55e64bbcc0cb3357a2bd83447a05400b8899
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382689
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The jittery clock and trng security features require high permissions to
be initialized. In the future these initializations and the permission
level drop may be moved to RO.
This change adds permission level checks before trying to access any
registers that require high permission, so when we update RO to change
the permission RW can still function fine.
BUG=chrome-os-partner:59107
BRANCH=none
TEST=Move the permission drop to the beginning of main and verify the
system still boots.
Change-Id: I5b7cb856decd0640288ad3476f875ec9edc42635
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405840
This patch adds the initial support for ISH chip to enable the EC
firmware to boot on Intel Integrated Sensor Hub (ISH). The following are
enabled:
1. Inter-Processor Communication (IPC) driver that enables the ISH to
communicate with the host Operating system via shared registers.
2. High Precision Event Timer (HPET) driver that provides configurable
timers for the FW to use in task scheduling.
3. I2C bus driver for accessing sensors.
4. UART console driver with TX support only.
BUG=chrome-os-partner:51851
BRANCH=None
TEST=`make buildall -j`
Change-Id: I15d4c201b799cfa79bed220ee573b75f5cd7b1f7
Signed-off-by: Jaiber John <jaiber.j.john@intel.com>
Signed-off-by: Alex Brill <alexander.brill@intel.com>
Signed-off-by: Gomathi Kumar <gomathi.kumar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/336710
Commit-Ready: Raj Mojumder <raj.mojumder@intel.com>
Tested-by: Jaiber J John <jaiber.j.john@intel.com>
Tested-by: Raj Mojumder <raj.mojumder@intel.com>
Reviewed-by: Jaiber J John <jaiber.j.john@intel.com>
Reviewed-by: Raj Mojumder <raj.mojumder@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We previously used binary extended Euclid. That does not perform well
when inverting a small public exponent.
We also abused that routine to perform the division of n by one of its
factors. Really did not perform well there either.
This CL introduces a classic Knuth long division and a normal extended
Euclid based on that.
This drops the execution time of the common inversions into the single
msec range (vs. multiple seconds before..)
TEST=tcg_tests pass the usual 381/391; test/tpm_test/bn_test passes.
BUG=chrome-os-partner:57422
BRANCH=none
Change-Id: Ic9b4aecd0356fcab3e823dbd60c5b228a87447d3
Reviewed-on: https://chromium-review.googlesource.com/406940
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This combines stm32 and chip/g usb_i2c interfaces so they
will not diverge. Note that this fixes the chip/g implementation
to use 8-bit i2c addresses.
BUG=chrome-os-partner:57059
BRANCH=none
TEST=servod interacts with servo_micro and servo_v4
Change-Id: Ibff217d84b132556202c8a71e3d42c07d546c634
Reviewed-on: https://chromium-review.googlesource.com/405108
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The i2c_xfer API assumes it's getting an 8 bit slave address, but the
driver was assuming a 7 bit slave address was being passed in. Fixed
the location where this is used to shift it back to 7 bits.
BRANCH=none
BUG=chrome-os-partner:57059
TEST=manual
Cr50 console 'ccd i2c on' then
> i2cxfer r16 0 0x40 0
Unknown error
Usage: i2cxfer r/r16/rlen/w/w16 port addr offset [value | len]
> i2cxfer r16 0 0x80 0
0x2771 [10097]
Shows that it's now assuming an 8 bit address
Change-Id: I791b7c136a741856749c281dd4c8166b5cf97ef9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405780
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
