| Message ID | 20171003204640.62236-1-guilherme.magalhaes@hpe.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Additionally, see the chart at: https://drive.google.com/file/d/0ByxwRmmxIzLYUm5WMm5BRmlkZWc/view?usp=sharing The X axis represents the number of processes executing new file access (measurements) and Y axis represents the total number of extends performed. The red line represents the workload using vTPM without any adjustment in the response polling sleep time. The purple line is with vTPM now with the polling sleep time adjustment. The IMA hash table, which causes performance degradation as indicated in my previous email, was removed from IMA to run these experiments as well. -- Guilherme > -----Original Message----- > From: Magalhaes, Guilherme (Brazil R&D-CL) > Sent: terça-feira, 3 de outubro de 2017 17:47 > To: linux-integrity@vger.kernel.org > Cc: Magalhaes, Guilherme (Brazil R&D-CL) <guilherme.magalhaes@hpe.com> > Subject: [PATCH] tpm: adjust command response sleep time for vTPM > > Once vTPM is actually a software, it is able to respond the commands much > quicker than physical TPMs. What we propose is to adjust the response > polling time to a usec value when the chip is detected as a vTPM. > With this change, the kernel TPM interface identifies whether the chip is > vTPM and on this case sets the polling sleep time to an optimized value. > > The performance result was 12x improvement when comparing PCR extends > using vTPM with the current sleep time and with the adjusted sleep time. > --- > drivers/char/tpm/tpm-interface.c | 6 +++++- > drivers/char/tpm/tpm.h | 2 ++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm- > interface.c > index 1d6729be4cd6..d213a3d4b305 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -455,7 +455,11 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct > tpm_space *space, > goto out; > } > > - tpm_msleep(TPM_TIMEOUT); > + if (chip->flags & TPM_CHIP_FLAG_VIRTUAL) > + usleep_range(TPM_TIMEOUT_VTPM_US, > TPM_TIMEOUT_VTPM_RANGE_US); > + else > + tpm_msleep(TPM_TIMEOUT); > + > rmb(); > } while (time_before(jiffies, stop)); > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h > index 2d5466a72e40..02d2dd761543 100644 > --- a/drivers/char/tpm/tpm.h > +++ b/drivers/char/tpm/tpm.h > @@ -50,6 +50,8 @@ enum tpm_const { > > enum tpm_timeout { > TPM_TIMEOUT = 5, /* msecs */ > + TPM_TIMEOUT_VTPM_US = 1, /* usecs */ > + TPM_TIMEOUT_VTPM_RANGE_US = 5, /* usecs */ > TPM_TIMEOUT_RETRY = 100, /* msecs */ > TPM_TIMEOUT_RANGE_US = 300 /* usecs */ > }; > -- > 2.11.0
On Tue, Oct 03, 2017 at 05:46:40PM -0300, Guilherme Magalhaes wrote: > Once vTPM is actually a software, it is able to respond the commands much > quicker than physical TPMs. What we propose is to adjust the response > polling time to a usec value when the chip is detected as a vTPM. > With this change, the kernel TPM interface identifies whether the chip is > vTPM and on this case sets the polling sleep time to an optimized value. > > The performance result was 12x improvement when comparing PCR extends > using vTPM with the current sleep time and with the adjusted sleep time. > --- > drivers/char/tpm/tpm-interface.c | 6 +++++- > drivers/char/tpm/tpm.h | 2 ++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c > index 1d6729be4cd6..d213a3d4b305 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -455,7 +455,11 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space, > goto out; > } > > - tpm_msleep(TPM_TIMEOUT); > + if (chip->flags & TPM_CHIP_FLAG_VIRTUAL) > + usleep_range(TPM_TIMEOUT_VTPM_US, TPM_TIMEOUT_VTPM_RANGE_US); > + else > + tpm_msleep(TPM_TIMEOUT); > + > rmb(); > } while (time_before(jiffies, stop)); > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h > index 2d5466a72e40..02d2dd761543 100644 > --- a/drivers/char/tpm/tpm.h > +++ b/drivers/char/tpm/tpm.h > @@ -50,6 +50,8 @@ enum tpm_const { > > enum tpm_timeout { > TPM_TIMEOUT = 5, /* msecs */ > + TPM_TIMEOUT_VTPM_US = 1, /* usecs */ > + TPM_TIMEOUT_VTPM_RANGE_US = 5, /* usecs */ > TPM_TIMEOUT_RETRY = 100, /* msecs */ > TPM_TIMEOUT_RANGE_US = 300 /* usecs */ > }; > -- > 2.11.0 > You should add me to to-field and CC this also to linux-kernel@vger.kernel.org linux-security-module@vger.kernel.org http://kernsec.org/wiki/index.php?title=Linux_Kernel_Integrity I managed to miss this patch and cannot accept it at this point because at minimum linux-kernel should be in the CC-list. I'm thinking what bad could happen if we shortened the timeout for hardware TPMs. /Jarkko
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 1d6729be4cd6..d213a3d4b305 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -455,7 +455,11 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space, goto out; } - tpm_msleep(TPM_TIMEOUT); + if (chip->flags & TPM_CHIP_FLAG_VIRTUAL) + usleep_range(TPM_TIMEOUT_VTPM_US, TPM_TIMEOUT_VTPM_RANGE_US); + else + tpm_msleep(TPM_TIMEOUT); + rmb(); } while (time_before(jiffies, stop)); diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index 2d5466a72e40..02d2dd761543 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -50,6 +50,8 @@ enum tpm_const { enum tpm_timeout { TPM_TIMEOUT = 5, /* msecs */ + TPM_TIMEOUT_VTPM_US = 1, /* usecs */ + TPM_TIMEOUT_VTPM_RANGE_US = 5, /* usecs */ TPM_TIMEOUT_RETRY = 100, /* msecs */ TPM_TIMEOUT_RANGE_US = 300 /* usecs */ };