tree ab3a224d299ff423634adf943f9184d548d4278d
parent acc841969a6eea70318dcfd52e1c4f749ad865b9
author Bill Richardson <wfrichar@chromium.org> 1475086638 -0700
committer chrome-bot <chrome-bot@chromium.org> 1475434138 -0700

Make sure errors are reported if NvCommit() fails

After handling a TPM command, the ExecuteCommand() function
does this:

  if(result == TPM_RC_SUCCESS)
  {
    // good things
  }
  else
  {
      // resTag and result indicate bad things

      if(result == TPM_RC_BAD_TAG)
          resTag = TPM_ST_RSP_COMMAND;
      else
          resTag = TPM_ST_NO_SESSIONS;
  }

  // Regardless, if NvCommit() is needed, call it.

  if(g_updateNV && !g_inFailureMode)
  {
      g_updateNV = FALSE;
      if(!NvCommit())
          FAIL(FATAL_ERROR_INTERNAL);
  }

The interesting bit is what happens if NvCommit() fails.

If EMBEDDED_MODE is not defined, there is a setjmp() at the top
of ExecuteCommand() and a longjmp() in the FAIL() function.
Together, these will force the TPM into a permanent failure
mode (until it is completely reset).

However, if EMBEDDED_MODE is defined, then the setjmp() is not
present, and the FAIL() function compiles into this:

  void TpmFail(const char *function, int line, int code)
  {
      memcpy(&s_failFunction, function, sizeof(s_failFunction));
      s_failLine = line;
      s_failCode = code;

      ;

      g_forceFailureMode = 0;
  }

which does nothing.

This CL doesn't put the TPM into permanent failure mode (because
we don't have a way to get out of it), but it does ensure that a
failure in NvCommit() is at least reported to the caller in the
same way that the unimplemented setjmp()/longjmp() would have done.

BUG=none
BRANCH=none
TEST=run TCG tests, test on Gru (log in/out, reboot, etc.)

All tests pass, no new failures seen (I didn't expect any)

Change-Id: Ibabacdae09efb06e36c6036424a23a47659d9bc3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/390335
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>