linux.git/drivers/char/tpm, branch v4.17

Merge branch 'next-tpm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2018-04-07T23:46:56+00:00

Pull TPM updates from James Morris:
 "This release contains only bug fixes. There are no new major features
  added"

* 'next-tpm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  tpm: fix intermittent failure with self tests
  tpm: add retry logic
  tpm: self test failure should not cause suspend to fail
  tpm2: add longer timeouts for creation commands.
  tpm_crb: use __le64 annotated variable for response buffer address
  tpm: fix buffer type in tpm_transmit_cmd
  tpm: tpm-interface: fix tpm_transmit/_cmd kdoc
  tpm: cmd_ready command can be issued only after granting locality

kernel.h: Retain constant expression output for max()/min()

2018-04-05T21:17:16+00:00

In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla.  However, this warning is overly pessimistic, in that
it is only happy with stack array sizes that are declared as constant
expressions, and not constant values.  One case of this is the
evaluation of the max() macro which, due to its construction, ends up
converting constant expression arguments into a constant value result.

All attempts to rewrite this macro with __builtin_constant_p() failed
with older compilers (e.g.  gcc 4.4)[2].  However, Martin Uecker,
constructed[3] a mind-shattering solution that works everywhere.
Cthulhu fhtagn!

This patch updates the min()/max() macros to evaluate to a constant
expression when called on constant expression arguments.  This removes
several false-positive stack VLA warnings from an x86 allmodconfig build
when -Wvla is added:

  $ diff -u before.txt after.txt | grep ^-
  -drivers/input/touchscreen/cyttsp4_core.c:871:2: warning: ISO C90 forbids variable length array ‘ids’ [-Wvla]
  -fs/btrfs/tree-checker.c:344:4: warning: ISO C90 forbids variable length array ‘namebuf’ [-Wvla]
  -lib/vsprintf.c:747:2: warning: ISO C90 forbids variable length array ‘sym’ [-Wvla]
  -net/ipv4/proc.c:403:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla]
  -net/ipv6/proc.c:198:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla]
  -net/ipv6/proc.c:218:2: warning: ISO C90 forbids variable length array ‘buff64’ [-Wvla]

This also updates two cases where different enums were being compared
and explicitly casts them to int (which matches the old side-effect of
the single-evaluation code): one in tpm/tpm_tis_core.h, and one in
drm/drm_color_mgmt.c.

 [1] https://lkml.org/lkml/2018/3/7/621
 [2] https://lkml.org/lkml/2018/3/10/170
 [3] https://lkml.org/lkml/2018/3/20/845

Co-Developed-by: Linus Torvalds 
Co-Developed-by: Martin Uecker 
Signed-off-by: Kees Cook 
Acked-by: Ingo Molnar 
Acked-by: Miguel Ojeda 
Signed-off-by: Linus Torvalds

tpm: fix intermittent failure with self tests

2018-03-23T08:25:09+00:00

My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background).  There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.

There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them.  It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command.  So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on.  In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.

Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.

[jarkko.sakkinen@linux.intel.com: cleaned up some klog messages and
 dropped tpm_transmit_check() helper function from James' original
 commit.]

Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: add retry logic

2018-03-23T08:25:09+00:00

TPM2 can return TPM2_RC_RETRY to any command and when it does we get
unexpected failures inside the kernel that surprise users (this is
mostly observed in the trusted key handling code).  The UEFI 2.6 spec
has advice on how to handle this:

    The firmware SHALL not return TPM2_RC_RETRY prior to the completion
    of the call to ExitBootServices().

    Implementer’s Note: the implementation of this function should check
    the return value in the TPM response and, if it is TPM2_RC_RETRY,
    resend the command. The implementation may abort if a sufficient
    number of retries has been done.

So we follow that advice in our tpm_transmit() code using
TPM2_DURATION_SHORT as the initial wait duration and
TPM2_DURATION_LONG as the maximum wait time.  This should fix all the
in-kernel use cases and also means that user space TSS implementations
don't have to have their own retry handling.

Signed-off-by: James Bottomley 
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: self test failure should not cause suspend to fail

2018-03-23T08:25:02+00:00

The Acer Acer Veriton X4110G has a TPM device detected as:
  tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)

After the first S3 suspend, the following error appears during resume:
  tpm tpm0: A TPM error(38) occurred continue selftest

Any following S3 suspend attempts will now fail with this error:
  tpm tpm0: Error (38) sending savestate before suspend
  PM: Device 00:0b failed to suspend: error 38

Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.

The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.

The platform behaviour seems broken here, but we should not break
suspend/resume because of this.

When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.

Cc: stable@vger.kernel.org
Signed-off-by: Chris Chiu 
Signed-off-by: Daniel Drake 
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm2: add longer timeouts for creation commands.

2018-03-23T08:18:06+00:00

TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve generation
of crypto keys which can be a computationally intensive task. The timeout
is set to 3min. Rather than increasing default timeout a new constant is
added, to not stall for too long on regular commands failures.

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm_crb: use __le64 annotated variable for response buffer address

2018-03-23T08:18:06+00:00

use __le64 annotated variable for response buffer address as this is
read in little endian format form the register.

This suppresses sparse warning
drivers/char/tpm/tpm_crb.c:558:18: warning: cast to restricted __le64

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: fix buffer type in tpm_transmit_cmd

2018-03-23T08:18:06+00:00

1. The buffer cannot be const as it is used both for send and receive.
2. Drop useless casting to u8 *, as this is already a
type of 'buf' parameter, it has just masked the 'const' issue.

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: tpm-interface: fix tpm_transmit/_cmd kdoc

2018-03-23T08:18:05+00:00

Fix tmp_ -> tpm_ typo and add reference to 'space' parameter
in kdoc for tpm_transmit and tpm_transmit_cmd functions.

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: cmd_ready command can be issued only after granting locality

2018-03-23T08:18:05+00:00

The correct sequence is to first request locality and only after
that perform cmd_ready handshake, otherwise the hardware will drop
the subsequent message as from the device point of view the cmd_ready
handshake wasn't performed. Symmetrically locality has to be relinquished
only after going idle handshake has completed, this requires that
go_idle has to poll for the completion and as well locality
relinquish has to poll for completion so it is not overridden
in back to back commands flow.

Two wrapper functions are added (request_locality relinquish_locality)
to simplify the error handling.

The issue is only visible on devices that support multiple localities.

Fixes: 877c57d0d0ca ("tpm_crb: request and relinquish locality 0")
Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen