linux-kernel - Re: FW: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Nov 2017 16:18:53 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     flihp <flihp@...bit.us>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org, Peter Huewe <peterhuewe@....de>,
        "Tricca, Philip B" <philip.b.tricca@...el.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        linux-integrity@...r.kernel.org,
        "Roberts, William C" <william.c.roberts@...el.com>
Subject: Re: FW: [RFC PATCH] tpm: don't return -EINVAL if TPM command
 validation fails

On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
> The intent of this "mostly transparent" stuff is to convey that the RM
> should be as transparent as possible while acknowledging that there are
> some cases where it's not / can't be. I can't say why the original
> author phrased it in this somewhat ambiguous way but I wouldn't call
> this a fair interpretation. It's definitely one way to read it though.
> 
> The case in question is the RM performing a function on behalf of the
> TPM: command code validation. This is a perfectly valid thing to do in
> the RM though the RM should aim to behave as the TPM would if the RM
> takes any action (sending a TPM response buffer with the appropriate
> response code).
> 
> An additional detail is described in section 3.1 "Error Codes". There is
> a mechanism to encode information about which layer in the stack
> produced the response buffer. When the TPM gets a command with a command
> code it doesn't support then this field will be '0' since '0' identifies
> the TPM. If the RM is taking over this function it should set the field
> to indicate as much.

Thanks for explaining this. I guess we could take this direction. I think
by utilizing the field that you mentioned we could consider this. And it
would be hard to imagine this change to cause anything serious (if
anything at all) with backwards compatbility.

Javier, does you current version use this field? If not can you resend
an update?

/Jarkko