[PATCH v6 02/12] tpm-buf: add handling for TPM2B types
Jarkko Sakkinen
jarkko.sakkinen at linux.intel.com
Wed Sep 25 12:34:01 UTC 2019
On Tue, Sep 24, 2019 at 07:12:40AM -0400, James Bottomley wrote:
> I thought about that. The main problem is that most of the
> construct/append functions use the header, and these are the functions
> most useful to the TPM2B operation.
>
> The other thing that argues against this is that the TPM2B case would
> save nothing if we eliminated the header, because we allocate a page
> for all the data regardless.
It would be way more clean. There is absolutely nothing TPM2B specific.
> > and also it makes sense to have a separate length field in the
> > struct to keep the code sane given that sometimes the buffer does not
> > store the length.
>
> I'm really not sure about that one. The header length has to be filled
> in for the non-TPM2B case but right at the moment we have no finish
> function for the buf where it could be, so we'd end up having to
> maintain two lengths in every update operation on non-TPM2B buffers.
> That seems inefficient and the only slight efficiency we get in the
> TPM2B case is not having to do the big endian conversion from the
> header which doesn't seem to be worth the added complexity.
It would be way more clean and an insignificant concern when it comes
to performance. I don't see any problem updating two lengths.
/Jarkko
More information about the Linux-security-module-archive
mailing list