All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>, linux-integrity@vger.kernel.org
Subject: Re: TPM legacy
Date: Sun, 2 Dec 2018 15:13:27 -0800	[thread overview]
Message-ID: <20181202231327.GC6718@linux.intel.com> (raw)
In-Reply-To: <1543775366.2732.24.camel@HansenPartnership.com>

On Sun, Dec 02, 2018 at 10:29:26AM -0800, James Bottomley wrote:
> The distros won't thank you for yet another kconfig option. ,
> especially one which could cause regressions if they choose the wrong
> value. However, having a hidden one which could be activated by driver
> might work ... on the other hand almost all the current drivers support
> both 1.2 and 2.0 so they'd all need splitting.

By default on (i.e. have TPM 1.x) and with a well thought documentation
should not be too bad.

> The other thing that should give us pause is this:
> 
> jejb@jarvis:~/git/linux/drivers/char/tpm> size tpm.o
>    text	   data	    bss	    dec	    hex	
> filename
>   35247	   1120	     32	  36399	   8e2f	
> tpm.o
> 
> Currently the combined tpm subsystem (without drivers) is less than 36k
> of code, so is splitting it up valuable?  I think you're going to find
> we have a reasonable abstraction of sharing, so taking out 1.x by
> config will likely save less than 10k of code ... is that worth the
> effort?

It is not only a size question. All unused code is always potential
attack surface. If the option is by default off and properly documented,
it should be IMHO ok.

It is fairly easy to do as TPM 1.x commands have been already put into
their own file thanks to Tomas.

/Jarkko

  reply	other threads:[~2018-12-02 23:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 23:35 TPM legacy Jarkko Sakkinen
2018-12-02 15:23 ` Mimi Zohar
2018-12-02 18:29   ` James Bottomley
2018-12-02 23:13     ` Jarkko Sakkinen [this message]
2018-12-03 15:01       ` Aw: " Peter Huewe
2018-12-03 17:29         ` Jason Gunthorpe
2018-12-03 17:55           ` Jarkko Sakkinen
2018-12-03 17:55             ` Jarkko Sakkinen
2018-12-03 18:00               ` Peter Huewe
2018-12-03 18:09                 ` Jason Gunthorpe
2018-12-03 18:15                   ` Jarkko Sakkinen
2018-12-03 18:15                     ` Jarkko Sakkinen
2018-12-03 17:30         ` Jarkko Sakkinen
2018-12-02 23:08   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181202231327.GC6718@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.