linux-kernel - Re: [PATCH] [RFC] TPM: be silent if disabled or deactivated

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]

Message-ID: <20120424144708.GA29206@localhost.br.ibm.com>
Date:	Tue, 24 Apr 2012 11:47:08 -0300
From:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Debora Velarde <debora@...ux.vnet.ibm.com>,
	Marcel Selhorst <m.selhorst@...rix.com>,
	tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] TPM: be silent if disabled or deactivated

On Thu, 12 Apr 2012, Paul Bolle wrote:

> Since v3.3 the TPM security chip on a laptop I use prints two messages
> at every boot and every resume:
>     tpm_tis 00:0a: A TPM error (6) occurred attempting to read a pcr value
>     tpm_tis 00:0a: TPM is disabled/deactivated (0x6)
> 
> The second message is just an informational message, indicating that
> this chip is deactivated (0x6 is TPM_ERR_DEACTIVATED). That doesn't
> bother me. The first message is printed at KERN_ERR level. To me it
> seems that it is not an error if a security chip is deactivated or
> disabled. So suppress that error message in those two cases.
> 
> Signed-off-by: Paul Bolle <pebolle@...cali.nl>
> ---
> 0) Tested against v3.3. (This laptop is currently tracking the Fedora 16
> kernel, which is now v3.3 based.) Applies cleanly to v3.4-rc2.
> 
> 1) Sent as an RFC because I don't actually use any TPM functionality.
> (At least, that's what I think. I'm entirely unfamiliar with TPM.)
> Moreover, there are a number of code paths that hit this messages, and
> for some of those this patch might hide this error where people still
> would like to see it. But my usage probably doesn't trigger those code
> paths.
>

Thanks for pointing this out Paul. We indeed don't want this being
thrown out as an error if the TPM is in this state. Although your patch
fits well and solves this neatly, transmit_cmd(), as you mentioned, is
called by essentially all functions attempting to send a command to the
TPM. Therefore, we do want to trigger this as an error in case a faulty
hardware claims to be functional after the tpm_do_selftest(), but decides
to return this error code when already registered. I'll modify
tpm_do_selftest() to handle these two scenarios. 

Rajiv

>  drivers/char/tpm/tpm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
> index 32362cf..40a09b5 100644
> --- a/drivers/char/tpm/tpm.c
> +++ b/drivers/char/tpm/tpm.c
> @@ -473,7 +473,7 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
>  		return -EFAULT;
> 
>  	err = be32_to_cpu(cmd->header.out.return_code);
> -	if (err != 0)
> +	if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED)
>  		dev_err(chip->dev, "A TPM error (%d) occurred %s\n", err, desc);
> 
>  	return err;
> -- 
> 1.7.7.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/