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

Message-Id: <1586880672.7311.212.camel@linux.ibm.com>
Date:   Tue, 14 Apr 2020 12:11:12 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Tianjia Zhang <tianjia.zhang@...ux.alibaba.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,
        Kenneth Goldman <kgoldman@...ibm.com>,
        Monty Wiseman <monty.wiseman@...com>,
        David Safford <david.safford@...il.com>
Subject: Re: [PATCH] ima: optimize ima_pcr_extend function by asynchronous

[Cc'ing Ken Goldman, Monty Wiseman, and Dave Safford]

On Tue, 2020-04-14 at 19:50 +0800, 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.
> 
> Because the return result of ima_pcr_extend() is of no concern to IMA,
> it only affects the audit of IMA, so this patch use async_schedule()
> to asynchronously perform the ima_pcr_extend() operation and do an
> audit operation at the end.
> 
> In a vtpm scenario, I added the measure policy of BPRM and MMAP to
> compare the efficiency before and after applying the patch. The results
> show that the overall startup efficiency of conventional processes can
> be increased by 5% to 10%. I believe this efficiency increase It will
> be more obvious on real hardware tpm.

Yes, we're fully aware that extending the TPM PCR takes a long time.
 That is the reason for a lot of Nayna Jain's and my work on improving
the TPM performance.

At one point, I implemented queueing the measurements without waiting
for the measurements to extend the TPM.  The performance was
absolutely amazing, but not waiting for the TPM extend to complete
violates the trusted boot principle of measuring and extending the TPM
PCR before use.

Secondly, the IMA measurement list order and the order in which the
measurements extend the TPM is really important in order to be able to
validate the IMA measurement list against the TPM PCR quote.

One solution that we've considered is batching the measurements, so
that the TPM PCR is extended with the hash of the batched
measurements, instead of each measurement.  The IMA measurement list
would continue to contain the individual measurements, but would also
need to indicate start/stop of the batched measurement group.  None of
this is trivial.

Mimi