[PATCH AliOS 4.19 v3 11/15] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Roberto Sassu roberto.sassu@huawei.com
commit 2d6c25215ab26bb009de3575faab7b685f138e92 upstream.
Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a TPM") allows the trusted module to be loaded even if a TPM is not found, to avoid module dependency problems.
However, trusted module initialization can still fail if the TPM is inactive or deactivated. tpm_get_random() returns an error.
This patch removes the call to tpm_get_random() and instead extends the PCR specified by the user with zeros. The security of this alternative is equivalent to the previous one, as either option prevents with a PCR update unsealing and misuse of sealed data by a user space process.
Even if a PCR is extended with zeros, instead of random data, it is still computationally infeasible to find a value as input for a new PCR extend operation, to obtain again the PCR value that would allow unsealing.
Cc: stable@vger.kernel.org Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...") Signed-off-by: Roberto Sassu roberto.sassu@huawei.com Reviewed-by: Tyler Hicks tyhicks@canonical.com Suggested-by: Mimi Zohar zohar@linux.ibm.com Reviewed-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com Signed-off-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com
Signed-off-by: mayuanchen mayuanchen@hygon.cn Change-Id: Iada0e052c2ab4a0fbc2db4ac2690da3115d985c6 Signed-off-by: Shan chenshan@hygon.cn --- security/keys/trusted.c | 13 ------------- 1 file changed, 13 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c index 5e983eb9a..b03525d0f 100644 --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1216,24 +1216,11 @@ static int __init trusted_shash_alloc(void)
static int __init init_digests(void) { - u8 digest[TPM_MAX_DIGEST_SIZE]; - int ret; - int i; - - ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE); - if (ret < 0) - return ret; - if (ret < TPM_MAX_DIGEST_SIZE) - return -EFAULT; - digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests), GFP_KERNEL); if (!digests) return -ENOMEM;
- for (i = 0; i < chip->nr_allocated_banks; i++) - memcpy(digests[i].digest, digest, TPM_MAX_DIGEST_SIZE); - return 0; }
On Tue, Dec 15, 2020 at 04:29:18PM +0800, Shan wrote:
From: Roberto Sassu roberto.sassu@huawei.com
commit 2d6c25215ab26bb009de3575faab7b685f138e92 upstream.
Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a TPM") allows the trusted module to be loaded even if a TPM is not found, to avoid module dependency problems.
However, trusted module initialization can still fail if the TPM is inactive or deactivated. tpm_get_random() returns an error.
This patch removes the call to tpm_get_random() and instead extends the PCR specified by the user with zeros. The security of this alternative is equivalent to the previous one, as either option prevents with a PCR update unsealing and misuse of sealed data by a user space process.
Even if a PCR is extended with zeros, instead of random data, it is still computationally infeasible to find a value as input for a new PCR extend operation, to obtain again the PCR value that would allow unsealing.
Cc: stable@vger.kernel.org Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...") Signed-off-by: Roberto Sassu roberto.sassu@huawei.com Reviewed-by: Tyler Hicks tyhicks@canonical.com Suggested-by: Mimi Zohar zohar@linux.ibm.com Reviewed-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com Signed-off-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com
Signed-off-by: mayuanchen mayuanchen@hygon.cn Change-Id: Iada0e052c2ab4a0fbc2db4ac2690da3115d985c6 Signed-off-by: Shan chenshan@hygon.cn
security/keys/trusted.c | 13 ------------- 1 file changed, 13 deletions(-)
Why is this being sent to the stable list? Do you want this backported to 4.19.y? If so, why, and what is the change-id stuff in there for?
confused,
greg k-h
-Shan
-----邮件原件----- 发件人: Greg KH [mailto:gregkh@linuxfoundation.org] 发送时间: 2020年12月15日 17:24 收件人: Shan Chen chenshan@hygon.cn 抄送: alikernel-developer@linux.alibaba.com; Roberto Sassu roberto.sassu@huawei.com; Yuanchen Ma mayuanchen@hygon.cn; Hao Feng fenghao@hygon.cn; Zhiwei Ying yingzhiwei@hygon.cn; stable@vger.kernel.org; Jarkko Sakkinen jarkko.sakkinen@linux.intel.com 主题: Re: [PATCH AliOS 4.19 v3 11/15] KEYS: trusted: allow module init if TPM is inactive or deactivated
On Tue, Dec 15, 2020 at 04:29:18PM +0800, Shan wrote:
From: Roberto Sassu roberto.sassu@huawei.com
commit 2d6c25215ab26bb009de3575faab7b685f138e92 upstream.
Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a TPM") allows the trusted module to be loaded even if a TPM is not found, to avoid module dependency problems.
However, trusted module initialization can still fail if the TPM is inactive or deactivated. tpm_get_random() returns an error.
This patch removes the call to tpm_get_random() and instead extends the PCR specified by the user with zeros. The security of this alternative is equivalent to the previous one, as either option prevents with a PCR update unsealing and misuse of sealed data by a user
space process.
Even if a PCR is extended with zeros, instead of random data, it is still computationally infeasible to find a value as input for a new PCR extend operation, to obtain again the PCR value that would allow
unsealing.
Cc: stable@vger.kernel.org Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...") Signed-off-by: Roberto Sassu roberto.sassu@huawei.com Reviewed-by: Tyler Hicks tyhicks@canonical.com Suggested-by: Mimi Zohar zohar@linux.ibm.com Reviewed-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com Signed-off-by: Jarkko Sakkinen jarkko.sakkinen@linux.intel.com
Signed-off-by: mayuanchen mayuanchen@hygon.cn Change-Id: Iada0e052c2ab4a0fbc2db4ac2690da3115d985c6 Signed-off-by: Shan chenshan@hygon.cn
security/keys/trusted.c | 13 ------------- 1 file changed, 13 deletions(-)
Why is this being sent to the stable list? Do you want this backported to 4.19.y? If so, why, and what is the change-id stuff in there for?
confused,
greg k-h
Sorry for the disturbing, it's not meant for the kernel community. We're backporting this commit for some private usage, and carelessly sent out this mail as git send-email automatically cc'ed the sob listed addresses. Have had the cc suppressed. pls ignore. Thanks!
Shan
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Shan -
Shan Chen