Re: [PATCH 03/12] tpm: add buffer handling for TPM2B types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2023-02-27 at 10:31 +0200, Jarkko Sakkinen wrote:
> On Thu, Feb 16, 2023 at 03:14:01PM -0500, James Bottomley wrote:
> > Most complex TPM commands require appending TPM2B buffers to the
> > command body.  Since TPM2B types are essentially variable size
> > arrays, it makes it impossible to represent these complex command
> > arguments as structures and we simply have to build them up using
> > append primitives like these.
> > 
> > Signed-off-by: James Bottomley
> > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> > ---
> >  drivers/char/tpm/tpm-buf.c | 71
> > +++++++++++++++++++++++++++++++++++---
> >  include/linux/tpm.h        |  3 ++
> >  2 files changed, 69 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-buf.c b/drivers/char/tpm/tpm-
> > buf.c
> > index ca59b92e0f95..292c6f14f72c 100644
> > --- a/drivers/char/tpm/tpm-buf.c
> > +++ b/drivers/char/tpm/tpm-buf.c
> > @@ -7,17 +7,16 @@
> >  #include <linux/module.h>
> >  #include <linux/tpm.h>
> >  
> > -int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
> > +static int __tpm_buf_init(struct tpm_buf *buf)
> >  {
> >         buf->data = (u8 *)__get_free_page(GFP_KERNEL);
> >         if (!buf->data)
> >                 return -ENOMEM;
> >  
> >         buf->flags = 0;
> > -       tpm_buf_reset(buf, tag, ordinal);
> > +
> >         return 0;
> >  }
> > -EXPORT_SYMBOL_GPL(tpm_buf_init);
> >  
> >  void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)
> >  {
> > @@ -29,17 +28,60 @@ void tpm_buf_reset(struct tpm_buf *buf, u16
> > tag, u32 ordinal)
> >  }
> >  EXPORT_SYMBOL_GPL(tpm_buf_reset);
> >  
> > +int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
> > +{
> > +       int rc;
> > +
> > +       rc = __tpm_buf_init(buf);
> > +       if (rc)
> > +               return rc;
> > +
> > +       tpm_buf_reset(buf, tag, ordinal);
> > +
> > +       return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tpm_buf_init);
> > +
> > +int tpm_buf_init_2b(struct tpm_buf *buf)
> 
> kdoc

I'm currently working on adding kdoc to everything.  However:

> > +{
> > +       struct tpm_header *head;
> > +       int rc;
> > +
> > +       rc = __tpm_buf_init(buf);
> > +       if (rc)
> > +               return rc;
> > +
> > +       head = (struct tpm_header *) buf->data;
> > +
> > +       head->length = cpu_to_be32(sizeof(*head));
> > +
> > +       buf->flags = TPM_BUF_2B;
> 
> Please make tpm_buf_init() and tpm_buf_reset() to work for both
> cases.

That's not a good idea: tpm_buf_init() and tpm_buf_reset() are used to
initialize *command* buffers.  tpm_buf_init_2b() is used for parameters
within commands and can't encompass whole commands, so the arguments
are different (that's why tpm_buf_init_2b() has no tag or ordinal).

> This explodes the whole thing into an unmaintainable mess. It is
> better to have a type as a parameter for tpm_buf_init() and have only
> single flow instead of open coded and patched variation.
> 
> I'd simply just put it as:
> 
> struct tpm_buf *tpm_buf_init(u16 tag, u32 ordinal, bool tpm2b)

The convention in Linux is that it's better to have named initializers
if we can rather than use less obvious booleans or flags ... think the
conversion from printk(KERN_ERR, ...) to pr_err(...)

Additionally tag and ordinal have no meaning for a tpm2b, so you're
really gluing two incompatible initializations into one which is bound
to cause confusion.

I've no objection in principle to doing a reset of a tpm2b (except,
again, it has no use for tag or ordinal) but I've just not got any code
that would use it, so I was leaving it out until someone had an actual
use case.

[...]
> > index 150b39b6190e..f2d4dab6d832 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -300,6 +300,7 @@ struct tpm_header {
> >  
> >  enum tpm_buf_flags {
> >         TPM_BUF_OVERFLOW        = BIT(0),
> > +       TPM_BUF_2B              = BIT(1),
> >  };
> 
> 
> This is IMHO unnecessary complex.
> 
> I think we could just have two bools:
> 
>         bool overflow;
>         bool tpm2b;

The advice (in the coding-style.rst bool section) is not to do this but
go the other way (so use flags instead of a string of bools).  The
reason is that even though bool represents a true/false value, it
usually takes one machine word (32 bits or sometimes more) to do it, so
bools tend to bloat structures over single bit fields.

James




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux