linux-kernel - Re: [PATCH] ima: optimize ima_pcr

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] [day] [month] [year] [list]

Date:   Wed, 15 Apr 2020 10:53:06 +0800
From:   Tianjia Zhang <tianjia.zhang@...ux.alibaba.com>
To:     Ken Goldman <kgold@...ux.ibm.com>, zohar@...ux.ibm.com,
        dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
        zhangliguang@...ux.alibaba.com, zhang.jia@...ux.alibaba.com
Cc:     linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ima: optimize ima_pcr_extend function by asynchronous



On 2020/4/15 2:07, Ken Goldman wrote:
> I wonder if there's a different issue?  I just ran selftest with 
> fullTest = yes in two different TPM vendors.
> 
> One took 230 msec, the other 320 msec.
> 
> I've never seen anything near 10 seconds.
> 
> Note that this is worse than the worst case because it's forcing a full 
> retest.  The TPM typically starts its self test immediately at power up 
> and could be complete by the time the OS starts to boot.
> 
> When I run selftest with fullTest = no, I get 30 msec, probably
> because it's not doing anything.
> 
> On 4/14/2020 7:50 AM, Tianjia Zhang wrote:
>> Because ima_pcr_extend() to operate the TPM chip, this process is
>> very time-consuming, for IMA, this is a blocking action, especially
>> when the TPM is in self test state, this process will block for up
>> to ten seconds.
> 

Ten seconds is an extreme scenario, and I haven't seen this worst case, 
but the TPM driver will fail to return in this scenario.

Thanks and best,
Tianjia