From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Zimmerman Subject: Re: [PATCH v4 1/2] tpm: Issue a TPM2_Shutdown for TPM2 devices. Date: Wed, 31 May 2017 15:08:38 -0700 Message-ID: References: <20170530050701.drf6geqplnfezllv@intel.com> <20170531120103.y6qf4v6hktzdbysx@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170531120103.y6qf4v6hktzdbysx-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jarkko Sakkinen Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net On Wed, May 31, 2017 at 5:01 AM, Jarkko Sakkinen wrote: > On Tue, May 30, 2017 at 12:00:53PM -0700, Josh Zimmerman wrote: >> On Mon, May 29, 2017 at 10:07 PM, Jarkko Sakkinen >> wrote: >> > On Thu, May 25, 2017 at 04:20:28PM -0700, Josh Zimmerman wrote: >> >> If a TPM2 loses power without a TPM2_Shutdown command being issued (a >> >> "disorderly reboot"), it may lose some state that has yet to be >> >> persisted to NVRam, and will increment the DA counter. After the DA >> >> counter gets sufficiently large, the TPM will lock the user out. >> >> >> >> NOTE: This only changes behavior on TPM2 devices. Since TPM1 uses sysfs, >> >> and sysfs relies on implicit locking on chip->ops, it is not safe to >> >> allow this code to run in TPM1, or to add sysfs support to TPM2, until >> >> that locking is made explicit. >> >> >> >> Signed-off-by: Josh Zimmerman >> >> Reviewed-by: Jarko Sakkinen >> >> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> > >> > Still have some remarks. >> > >> >> ---- >> >> v2: >> >> - Properly split changes between this and another commit >> >> - Use proper locking primitive. >> >> - Fix commenting style >> >> v3: >> >> - Re-fix commenting style >> >> v4: >> >> - Update description and tags (Reviewed-by, Cc). >> >> --- >> >> --- >> >> drivers/char/tpm/tpm-chip.c | 20 ++++++++++++++++++++ >> >> drivers/char/tpm/tpm-sysfs.c | 3 +++ >> >> 2 files changed, 23 insertions(+) >> >> >> >> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c >> >> index 9dec9f551b83..272a42e77574 100644 >> >> --- a/drivers/char/tpm/tpm-chip.c >> >> +++ b/drivers/char/tpm/tpm-chip.c >> >> @@ -142,6 +142,25 @@ static void tpm_devs_release(struct device *dev) >> >> put_device(&chip->dev); >> >> } >> >> >> >> +static void tpm_shutdown(struct device *dev) >> >> +{ >> >> + struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev); >> >> + /* TPM 2.0 requires that the TPM2_Shutdown() command be issued prior to >> >> + * loss of power. If it is not, the DA counter will be incremented and, >> >> + * eventually, the user will be locked out of their TPM. >> >> + * XXX: This codepath relies on the fact that sysfs is not enabled for >> >> + * TPM2: sysfs uses an implicit lock on chip->ops, so this use could >> >> + * race if TPM2 has sysfs support enabled before TPM sysfs's implicit >> >> + * locking is fixed. >> >> + */ >> > >> > The comment should be either deleted or a kdoc. >> Done. >> >> >> + if (chip->flags & TPM_CHIP_FLAG_TPM2) { >> >> + down_write(&chip->ops_sem); >> >> + tpm2_shutdown(chip, TPM_SU_CLEAR); >> >> + chip->ops = NULL; >> >> + up_write(&chip->ops_sem); >> >> + } >> >> +} >> > >> > Would be a better idea to rename tpm2_shutdown as tpm_shutdown and call >> > it unconditionally in tpm_del_char_device. >> I'm not sure quite what you mean here. Are you suggesting that >> tpm_del_char_device should unconditionally call the tpm_shutdown that >> this patch introduces? Or that the tpm2_shutdown function from >> drivers/char/tpm/tpm2-cmd.c (which right now just sends the >> TPM2_Shutdown command) be renamed to tpm_shutdown? > > The second option. I'm afraid I don't quite understand. I believe that tpm2_shutdown is currently quite specific to the TPM2 devices. It can also be called when preparing for hibernation, in which case we may not want to NULL out chip->ops. Can you please explain again what you'd like me to accomplish by making this change? > In addition can make that your patch set applies to > security/next so I can merge both. I realized that the first patch does > not apply so that needs a resend too. Replied in the other thread. This patch appears to apply cleanly on the branch I mentioned there. > >> >> + >> >> /** >> >> * tpm_chip_alloc() - allocate a new struct tpm_chip instance >> >> * @pdev: device to which the chip is associated >> >> @@ -181,6 +200,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev, >> >> device_initialize(&chip->devs); >> >> >> >> chip->dev.class = tpm_class; >> >> + chip->dev.class.shutdown = tpm_shutdown; >> >> chip->dev.release = tpm_dev_release; >> >> chip->dev.parent = pdev; >> >> chip->dev.groups = chip->groups; >> >> diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c >> >> index 55405dbe43fa..5e5ff7eb6f7e 100644 >> >> --- a/drivers/char/tpm/tpm-sysfs.c >> >> +++ b/drivers/char/tpm/tpm-sysfs.c >> >> @@ -294,6 +294,9 @@ static const struct attribute_group tpm_dev_group = { >> >> >> >> void tpm_sysfs_add_device(struct tpm_chip *chip) >> >> { >> >> + /* XXX: Before this restriction is removed, tpm_sysfs must be updated >> >> + * to explicitly lock chip->ops. >> >> + */ >> > >> > Not sure about this remark. Most, if not all, attributes in tpm-sysfs.c >> > are useless attributes as you can use /dev/tpm0 to retrieve their >> > values. >> This is again in reference to >> https://patchwork.kernel.org/patch/9516631/; if at some point in the >> future a developer wishes to enable sysfs support for TPM2.0, the >> implicit locking must be fixed. >> >> I've attempted to clarify the phrasing here. >> >> Josh > > OK lets keep it! > > /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot