On Tue, Jun 20, 2017 at 11:32:41PM +0200, Jarkko Sakkinen wrote:

On Tue, Jun 20, 2017 at 05:25:57PM -0400, Stefan Berger wrote:

quoted

On 06/20/2017 04:55 PM, Jarkko Sakkinen wrote:

quoted

On Tue, Jun 20, 2017 at 01:31:52PM -0600, Jason Gunthorpe wrote:

quoted

On Tue, Jun 20, 2017 at 08:13:34PM +0200, Jarkko Sakkinen wrote:

quoted

Consolidated all the "manual" TPM startup code to a single function
in order to make code flows a bit cleaner and migrate to tpm_buf.

Signed-off-by: Jarkko Sakkinen <redacted>
  drivers/char/tpm/tpm-interface.c | 67 +++++++++++++++++++++++++---------------
  drivers/char/tpm/tpm.h           |  6 +---
  drivers/char/tpm/tpm2-cmd.c      | 32 +------------------
  3 files changed, 44 insertions(+), 61 deletions(-)

Makes sense to me

quoted

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index d2b4df6d9894..fbef47d8bd06 100644
+++ b/drivers/char/tpm/tpm-interface.c

@@ -540,6 +540,47 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
  }
  EXPORT_SYMBOL_GPL(tpm_transmit_cmd);
+#define TPM_ORD_STARTUP 153
+#define TPM_ST_CLEAR 1

We should really have a tpm1.h and tpm2.h that has all these various
constants and things instead of open coding them randomly all over..

Jason

I agree.

Is this patch acceptable to be applied?

Stefan, can you peer test this with a TPM emulator? For convenient testing
I created 'readpubek' branch that includes also my readpubek bug fixes.
Seeing that the module loads and you can output pubek sysfs attribute is
sufficient for seeing that all the three patches work.

Doesn't work. The startup_type is be16, but you are appending a u32 now for
both TPM1.2 and TPM2.

+               tpm_buf_append_u32(&buf, TPM_ST_CLEAR);

Ah. Thanks. I'll fix that.

It's fixed in the 'readpubek' branch. If that is the only concern, can
you test that branch and see if it is OK so that we don't need a new
cycle for the patch set?

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html