Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 2月, 2015 1 次提交
    • J
      tpm: fix suspend/resume paths for TPM 2.0 · 74d6b3ce
      由 Jarkko Sakkinen 提交于 
      Fixed suspend/resume paths for TPM 2.0 and consolidated all the
associated code to the tpm_pm_suspend() and tpm_pm_resume()
functions. Resume path should be handled by the firmware, i.e.
Startup(CLEAR) for hibernate and Startup(STATE) for suspend.

There might be some non-PC embedded devices in the future where
Startup() is not the handled by the FW but fixing the code for
those IMHO should be postponed until there is hardware available
to test the fixes although extra Startup in the driver code is
essentially a NOP.

Added Shutdown(CLEAR) to the remove paths of TIS and CRB drivers.
Changed tpm2_shutdown() to a void function because there isn't
much you can do except print an error message if this fails with
a system error.

Fixes: aec04cbd ("tpm: TPM 2.0 FIFO Interface")
Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface")
[phuewe: both did send TPM_Shutdown on resume which 'disables' the TPM
and did not send TPM2_Shutdown on teardown which leads some TPM2.0 to
believe there was an attack (no TPM2_Shutdown = no orderly shutdown =
attack)]
Reported-by: NPeter Hüwe <PeterHuewe@gmx.de>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NScot Doyle <lkml14@scotdoyle.com>
Reviewed-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
      74d6b3ce
  3. 18 1月, 2015 1 次提交
  5. 17 1月, 2015 6 次提交
  7. 06 1月, 2014 6 次提交
  9. 23 10月, 2013 2 次提交
  11. 28 5月, 2013 1 次提交
  13. 22 5月, 2013 1 次提交
  15. 17 4月, 2013 1 次提交
    • D
      TPM: Retry SaveState command in suspend path · 32d33b29
      由 Duncan Laurie 提交于 
      If the TPM has already been sent a SaveState command before the driver
is loaded it may have problems sending that same command again later.

This issue is seen with the Chromebook Pixel due to a firmware bug in
the legacy mode boot path which is sending the SaveState command
before booting the kernel.  More information is available at
http://crbug.com/203524

This change introduces a retry of the SaveState command in the suspend
path in order to work around this issue.  A future firmware update
should fix this but this is also a trivial workaround in the driver
that has no effect on systems that do not show this problem.

When this does happen the TPM responds with a non-fatal TPM_RETRY code
that is defined in the specification:

  The TPM is too busy to respond to the command immediately, but the
  command could be resubmitted at a later time.  The TPM MAY return
  TPM_RETRY for any command at any time.

It can take several seconds before the TPM will respond again.  I
measured a typical time between 3 and 4 seconds and the timeout is set
at a safe 5 seconds.

It is also possible to reproduce this with commands via /dev/tpm0.
The bug linked above has a python script attached which can be used to
test for this problem.  I tested a variety of TPMs from Infineon,
Nuvoton, Atmel, and STMicro but was only able to reproduce this with
LPC and I2C TPMs from Infineon.

The TPM specification only loosely defines this behavior:

  TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
  The TPM MAY declare all preserved values invalid in response to any
  command other than TPM_Init.

  TCG PC Client BIOS Spec 1.21 section 8.3.1.
  After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
  commands before transitioning to S3 without issuing another
  TPM_SaveState command.

  TCG PC Client TIS 1.21, section 4. Power Management:
  The TPM_SaveState command allows a Static OS to indicate to the TPM
  that the platform may enter a low power state where the TPM will be
  required to enter into the D3 power state.  The use of the term "may"
  is significant in that there is no requirement for the platform to
  actually enter the low power state after sending the TPM_SaveState
  command.  The software may, in fact, send subsequent commands after
  sending the TPM_SaveState command.

Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
Signed-off-by: NKent Yoder <key@linux.vnet.ibm.com>
      32d33b29
  17. 05 2月, 2013 6 次提交
  19. 10 10月, 2012 1 次提交
  21. 23 8月, 2012 4 次提交
  23. 11 7月, 2012 1 次提交
  25. 15 2月, 2012 1 次提交
  27. 19 1月, 2012 1 次提交
  29. 16 11月, 2011 5 次提交
  31. 13 7月, 2011 2 次提交
    • S
      tpm_tis: Fix the probing for interrupts · a7b66822
      由 Stefan Berger 提交于 
      This patch fixes several aspects of the probing for interrupts.

This patch reads the TPM's timeouts before probing for the interrupts. The
tpm_get_timeouts() function is invoked in polling mode and gets the proper
timeouts from the TPM so that we don't need to fall back to 2 minutes timeouts
for short duration commands while the interrupt probing is happening.

This patch introduces a variable probed_irq into the vendor structure that gets
the irq number if an interrupt is received while the the tpm_gen_interrupt()
function is run in polling mode during interrupt probing. Previously some
parts of tpm_gen_interrupt() were run in polling mode, then the irq variable
was set in the interrupt handler when an interrupt was received and execution
of tpm_gen_interrupt() ended up switching over to interrupt mode.
tpm_gen_interrupt() execution ended up on an event queue where it eventually
timed out since the probing handler doesn't wake any queues.

Before calling into free_irq() clear all interrupt flags that may have
been set by the TPM. The reason is that free_irq() will call into the probing
interrupt handler and may otherwise fool us into thinking that a real interrupt
happened (because we see the flags as being set) while the TPM's interrupt line
is not even connected to anything on the motherboard. This solves a problem
on one machine I did testing on (Thinkpad T60).

If a TPM claims to use a specifc interrupt, the probing is done as well
to verify that the interrupt is actually working. If a TPM indicates
that it does not use a specific interrupt (returns '0'), probe all interrupts
from 3 to 15.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      a7b66822
    • S
      tpm_tis: Add timeouts sysfs entry · 62592101
      由 Stefan Berger 提交于 
      Display the TPM's interface timeouts in a 'timeouts' sysfs entry. Display
the entries as having been adjusted when they were scaled due to their values
being reported in milliseconds rather than microseconds.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      62592101