From: Stefan Berger <[email protected]>
QEMU 5.0 will support the PAPR vTPM device model for TPM 1.2 and TPM 2.0.
This series of patches enables vTPM 2.0 support for the IBM vTPM driver.
Regards,
Stefan
- v5->v6:
- Nits in commit texts
- v4->v5:
- Added error path in case tpm2_get_cc_attrs_tbl() fails
- v3->v4:
- Dropped patch 3; getting command code attributes table in IBM driver
- v2->v3:
- Added fixes tag to patch 2/4; the race seems to have existed
since the driver was first added
- Renamed tpm2_init to tpm2_init_commands in 3/4
- v1->v2:
- Addressed comments to v1; added patch 3 to handle case when
TPM_OPS_AUTO_STARTUP is not set
Stefan Berger (3):
tpm: of: Handle IBM,vtpm20 case when getting log parameters
tpm: ibmvtpm: Wait for buffer to be set before proceeding
tpm: ibmvtpm: Add support for TPM2
drivers/char/tpm/eventlog/of.c | 8 +++++++-
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 17 +++++++++++++++++
drivers/char/tpm/tpm_ibmvtpm.h | 1 +
5 files changed, 27 insertions(+), 2 deletions(-)
--
2.23.0
From: Stefan Berger <[email protected]>
Synchronize with the results from the CRQs before continuing with
the initialization. This avoids trying to send TPM commands while
the rtce buffer has not been allocated, yet.
This patch fixes an existing race condition that may occurr if the
hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
request sent during initialization and therefore the ibmvtpm->rtce_buf
has not been allocated at the time the first TPM command is sent.
Fixes: 132f76294744 ("Add new device driver to support IBM vTPM")
Signed-off-by: Stefan Berger <[email protected]>
---
drivers/char/tpm/tpm_ibmvtpm.c | 9 +++++++++
drivers/char/tpm/tpm_ibmvtpm.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 78cc52690177..cfe40e7b1ba4 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -571,6 +571,7 @@ static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
*/
while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
ibmvtpm_crq_process(crq, ibmvtpm);
+ wake_up_interruptible(&ibmvtpm->crq_queue.wq);
crq->valid = 0;
smp_wmb();
}
@@ -618,6 +619,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
}
crq_q->num_entry = CRQ_RES_BUF_SIZE / sizeof(*crq_q->crq_addr);
+ init_waitqueue_head(&crq_q->wq);
ibmvtpm->crq_dma_handle = dma_map_single(dev, crq_q->crq_addr,
CRQ_RES_BUF_SIZE,
DMA_BIDIRECTIONAL);
@@ -670,6 +672,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;
+ if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
+ ibmvtpm->rtce_buf != NULL,
+ HZ)) {
+ dev_err(dev, "CRQ response timed out\n");
+ goto init_irq_cleanup;
+ }
+
return tpm_chip_register(chip);
init_irq_cleanup:
do {
diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
index 7983f1a33267..b92aa7d3e93e 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.h
+++ b/drivers/char/tpm/tpm_ibmvtpm.h
@@ -26,6 +26,7 @@ struct ibmvtpm_crq_queue {
struct ibmvtpm_crq *crq_addr;
u32 index;
u32 num_entry;
+ wait_queue_head_t wq;
};
struct ibmvtpm_dev {
--
2.23.0
From: Stefan Berger <[email protected]>
Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
version of TPM is connected through the vio_device_id.
In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
and get the command codes attributes table. The driver does
not need the timeouts and durations, though.
Signed-off-by: Stefan Berger <[email protected]>
---
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 8 ++++++++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 2b2c225e1190..0fbcede241ea 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -226,6 +226,7 @@ int tpm2_auto_startup(struct tpm_chip *chip);
void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm2_probe(struct tpm_chip *chip);
+int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip);
int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
int tpm2_init_space(struct tpm_space *space);
void tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 760329598b99..76f67b155bd5 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -615,7 +615,7 @@ ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
return rc;
}
-static int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip)
+int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip)
{
struct tpm_buf buf;
u32 nr_commands;
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index cfe40e7b1ba4..1a49db9e108e 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -29,6 +29,7 @@ static const char tpm_ibmvtpm_driver_name[] = "tpm_ibmvtpm";
static const struct vio_device_id tpm_ibmvtpm_device_table[] = {
{ "IBM,vtpm", "IBM,vtpm"},
+ { "IBM,vtpm", "IBM,vtpm20"},
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
@@ -672,6 +673,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;
+ if (!strcmp(id->compat, "IBM,vtpm20")) {
+ chip->flags |= TPM_CHIP_FLAG_TPM2;
+ rc = tpm2_get_cc_attrs_tbl(chip);
+ if (rc)
+ goto init_irq_cleanup;
+ }
+
if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
ibmvtpm->rtce_buf != NULL,
HZ)) {
--
2.23.0
From: Stefan Berger <[email protected]>
A vTPM 2.0 is identified by 'IBM,vtpm20' in the 'compatible' node in
the device tree. Handle it in the same way as 'IBM,vtpm'.
The vTPM 2.0's log is written in little endian format so that for this
aspect we can rely on existing code.
Signed-off-by: Stefan Berger <[email protected]>
Acked-by: Jarkko Sakkinen <[email protected]>
---
drivers/char/tpm/eventlog/of.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
index af347c190819..a31a625ad44e 100644
--- a/drivers/char/tpm/eventlog/of.c
+++ b/drivers/char/tpm/eventlog/of.c
@@ -17,6 +17,12 @@
#include "../tpm.h"
#include "common.h"
+static const char * const compatibles[] = {
+ "IBM,vtpm",
+ "IBM,vtpm20",
+ NULL
+};
+
int tpm_read_log_of(struct tpm_chip *chip)
{
struct device_node *np;
@@ -51,7 +57,7 @@ int tpm_read_log_of(struct tpm_chip *chip)
* endian format. For this reason, vtpm doesn't need conversion
* but physical tpm needs the conversion.
*/
- if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
+ if (!of_device_compatible_match(np, compatibles)) {
size = be32_to_cpup((__force __be32 *)sizep);
base = be64_to_cpup((__force __be64 *)basep);
} else {
--
2.23.0
On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
> From: Stefan Berger <[email protected]>
>
> QEMU 5.0 will support the PAPR vTPM device model for TPM 1.2 and TPM 2.0.
> This series of patches enables vTPM 2.0 support for the IBM vTPM driver.
BTW, what is PAPR vTPM device model? Is it something that is used
generally for vTPM's or just in IBM context?
/Jarkko
On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
> From: Stefan Berger <[email protected]>
>
> Synchronize with the results from the CRQs before continuing with
> the initialization. This avoids trying to send TPM commands while
> the rtce buffer has not been allocated, yet.
>
> This patch fixes an existing race condition that may occurr if the
> hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
> request sent during initialization and therefore the ibmvtpm->rtce_buf
> has not been allocated at the time the first TPM command is sent.
>
> Fixes: 132f76294744 ("Add new device driver to support IBM vTPM")
> Signed-off-by: Stefan Berger <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
/Jarkko
On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
> From: Stefan Berger <[email protected]>
>
> Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
> version of TPM is connected through the vio_device_id.
>
> In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
> and get the command codes attributes table. The driver does
> not need the timeouts and durations, though.
>
> Signed-off-by: Stefan Berger <[email protected]>
There is huge bunch of people in the cc-list and these patches
have total zero tested-by's. Why is that?
/Jarkko
On 3/5/20 6:20 AM, Jarkko Sakkinen wrote:
> On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
>> From: Stefan Berger <[email protected]>
>>
>> QEMU 5.0 will support the PAPR vTPM device model for TPM 1.2 and TPM 2.0.
>> This series of patches enables vTPM 2.0 support for the IBM vTPM driver.
> BTW, what is PAPR vTPM device model? Is it something that is used
> generally for vTPM's or just in IBM context?
It's an IBM pSeries specification. The device model is only used on pSeries.
Stefan
>
> /Jarkko
>
On 3/5/20 6:21 AM, Jarkko Sakkinen wrote:
> On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
>> From: Stefan Berger <[email protected]>
>>
>> Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
>> version of TPM is connected through the vio_device_id.
>>
>> In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
>> and get the command codes attributes table. The driver does
>> not need the timeouts and durations, though.
>>
>> Signed-off-by: Stefan Berger <[email protected]>
> There is huge bunch of people in the cc-list and these patches
> have total zero tested-by's. Why is that?
I cc'ed them because of their involvement in other layers. That's all I
can say.
Stefan
>
> /Jarkko
>
On Thu, Mar 05, 2020 at 08:58:15AM -0500, Stefan Berger wrote:
> On 3/5/20 6:21 AM, Jarkko Sakkinen wrote:
> > On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
> > > From: Stefan Berger <[email protected]>
> > >
> > > Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
> > > version of TPM is connected through the vio_device_id.
> > >
> > > In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
> > > and get the command codes attributes table. The driver does
> > > not need the timeouts and durations, though.
> > >
> > > Signed-off-by: Stefan Berger <[email protected]>
> > There is huge bunch of people in the cc-list and these patches
> > have total zero tested-by's. Why is that?
>
>
> I cc'ed them because of their involvement in other layers. That's all I can
> say.
OK, so there is no one who can test this?
/Jarkko
On 3/6/20 1:33 PM, Jarkko Sakkinen wrote:
> On Thu, Mar 05, 2020 at 08:58:15AM -0500, Stefan Berger wrote:
>> On 3/5/20 6:21 AM, Jarkko Sakkinen wrote:
>>> On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
>>>> From: Stefan Berger <[email protected]>
>>>>
>>>> Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
>>>> version of TPM is connected through the vio_device_id.
>>>>
>>>> In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
>>>> and get the command codes attributes table. The driver does
>>>> not need the timeouts and durations, though.
>>>>
>>>> Signed-off-by: Stefan Berger <[email protected]>
>>> There is huge bunch of people in the cc-list and these patches
>>> have total zero tested-by's. Why is that?
>>
>> I cc'ed them because of their involvement in other layers. That's all I can
>> say.
> OK, so there is no one who can test this?
Nayna said she will test it next week.
Stefan
>
> /Jarkko
On Fri, Mar 06, 2020 at 01:51:30PM -0500, Stefan Berger wrote:
> On 3/6/20 1:33 PM, Jarkko Sakkinen wrote:
> > On Thu, Mar 05, 2020 at 08:58:15AM -0500, Stefan Berger wrote:
> > > On 3/5/20 6:21 AM, Jarkko Sakkinen wrote:
> > > > On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
> > > > > From: Stefan Berger <[email protected]>
> > > > >
> > > > > Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
> > > > > version of TPM is connected through the vio_device_id.
> > > > >
> > > > > In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
> > > > > and get the command codes attributes table. The driver does
> > > > > not need the timeouts and durations, though.
> > > > >
> > > > > Signed-off-by: Stefan Berger <[email protected]>
> > > > There is huge bunch of people in the cc-list and these patches
> > > > have total zero tested-by's. Why is that?
> > >
> > > I cc'ed them because of their involvement in other layers. That's all I can
> > > say.
> > OK, so there is no one who can test this?
>
> Nayna said she will test it next week.
That'd be great. Otherwise, I have no issues pulling the patches.
/Jarkko
On 3/7/20 6:09 AM, Jarkko Sakkinen wrote:
> On Fri, Mar 06, 2020 at 01:51:30PM -0500, Stefan Berger wrote:
>> On 3/6/20 1:33 PM, Jarkko Sakkinen wrote:
>>> On Thu, Mar 05, 2020 at 08:58:15AM -0500, Stefan Berger wrote:
>>>> On 3/5/20 6:21 AM, Jarkko Sakkinen wrote:
>>>>> On Wed, 2020-03-04 at 08:22 -0500, Stefan Berger wrote:
>>>>>> From: Stefan Berger <[email protected]>
>>>>>>
>>>>>> Support TPM2 in the IBM vTPM driver. The hypervisor tells us what
>>>>>> version of TPM is connected through the vio_device_id.
>>>>>>
>>>>>> In case a TPM2 device is found, we set the TPM_CHIP_FLAG_TPM2 flag
>>>>>> and get the command codes attributes table. The driver does
>>>>>> not need the timeouts and durations, though.
>>>>>>
>>>>>> Signed-off-by: Stefan Berger <[email protected]>
>>>>> There is huge bunch of people in the cc-list and these patches
>>>>> have total zero tested-by's. Why is that?
>>>> I cc'ed them because of their involvement in other layers. That's all I can
>>>> say.
>>> OK, so there is no one who can test this?
>> Nayna said she will test it next week.
> That'd be great. Otherwise, I have no issues pulling the patches.
>
> /Jarkko
I tested the patches, except testing of bugfix for vtpm1.2.
Here are my Ack-by/Tested-by for the patchset:
Acked-by: Nayna Jain <[email protected]>
Tested-by: Nayna Jain <[email protected]>
Thanks & Regards,
- Nayna
Hi Stefan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jss-tpmdd/next]
[also build test ERROR on powerpc/next linux/master linus/master v5.6-rc5 next-20200310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Stefan-Berger/Enable-vTPM-2-0-for-the-IBM-vTPM-driver/20200305-042731
base: git://git.infradead.org/users/jjs/linux-tpmdd next
config: xtensa-randconfig-a001-20200310 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=xtensa
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <[email protected]>
All errors (new ones prefixed by >>):
>> ERROR: "of_device_compatible_match" undefined!
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
On 3/10/20 6:56 PM, kbuild test robot wrote:
> Hi Stefan,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on jss-tpmdd/next]
> [also build test ERROR on powerpc/next linux/master linus/master v5.6-rc5 next-20200310]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Stefan-Berger/Enable-vTPM-2-0-for-the-IBM-vTPM-driver/20200305-042731
> base: git://git.infradead.org/users/jjs/linux-tpmdd next
> config: xtensa-randconfig-a001-20200310 (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 9.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=9.2.0 make.cross ARCH=xtensa
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <[email protected]>
I suppose I would only add this Report-by if this was an issue upstream?!