This is a note to let you know that I've just added the patch titled
tpm_crb: fix mapping of the buffers
to the 4.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tpm_crb-fix-mapping-of-the-buffers.patch
and it can be found in the queue-4.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 422eac3f7deae34dbaffd08e03e27f37a5394a56 Mon Sep 17 00:00:00 2001
From: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
Date: Tue, 19 Apr 2016 12:54:18 +0300
Subject: tpm_crb: fix mapping of the buffers
From: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
commit 422eac3f7deae34dbaffd08e03e27f37a5394a56 upstream.
On my Lenovo x250 the following situation occurs:
[18697.813871] tpm_crb MSFT0101:00: can't request region for resource
[mem 0xacdff080-0xacdfffff]
The mapping of the control area overlaps the mapping of the command
buffer. The control area is mapped over page, which is not right. It
should mapped over sizeof(struct crb_control_area).
Fixing this issue unmasks another issue. Command and response buffers
can overlap and they do interleave on this machine. According to the PTP
specification the overlapping means that they are mapped to the same
buffer.
The commit has been also on a Haswell NUC where things worked before
applying this fix so that the both code paths for response buffer
initialization are tested.
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
Reviewed-by: Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/char/tpm/tpm_crb.c | 39 ++++++++++++++++++++++++++++-----------
1 file changed, 28 insertions(+), 11 deletions(-)
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -259,7 +259,10 @@ static int crb_map_io(struct acpi_device
struct list_head resources;
struct resource io_res;
struct device *dev = &device->dev;
- u64 pa;
+ u64 cmd_pa;
+ u32 cmd_size;
+ u64 rsp_pa;
+ u32 rsp_size;
int ret;
INIT_LIST_HEAD(&resources);
@@ -280,22 +283,36 @@ static int crb_map_io(struct acpi_device
return PTR_ERR(priv->iobase);
priv->cca = crb_map_res(dev, priv, &io_res, buf->control_address,
- 0x1000);
+ sizeof(struct crb_control_area));
if (IS_ERR(priv->cca))
return PTR_ERR(priv->cca);
- pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
- (u64) ioread32(&priv->cca->cmd_pa_low);
- priv->cmd = crb_map_res(dev, priv, &io_res, pa,
- ioread32(&priv->cca->cmd_size));
+ cmd_pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
+ (u64) ioread32(&priv->cca->cmd_pa_low);
+ cmd_size = ioread32(&priv->cca->cmd_size);
+ priv->cmd = crb_map_res(dev, priv, &io_res, cmd_pa, cmd_size);
if (IS_ERR(priv->cmd))
return PTR_ERR(priv->cmd);
- memcpy_fromio(&pa, &priv->cca->rsp_pa, 8);
- pa = le64_to_cpu(pa);
- priv->rsp = crb_map_res(dev, priv, &io_res, pa,
- ioread32(&priv->cca->rsp_size));
- return PTR_ERR_OR_ZERO(priv->rsp);
+ memcpy_fromio(&rsp_pa, &priv->cca->rsp_pa, 8);
+ rsp_pa = le64_to_cpu(rsp_pa);
+ rsp_size = ioread32(&priv->cca->rsp_size);
+
+ if (cmd_pa != rsp_pa) {
+ priv->rsp = crb_map_res(dev, priv, &io_res, rsp_pa, rsp_size);
+ return PTR_ERR_OR_ZERO(priv->rsp);
+ }
+
+ /* According to the PTP specification, overlapping command and response
+ * buffer sizes must be identical.
+ */
+ if (cmd_size != rsp_size) {
+ dev_err(dev, FW_BUG "overlapping command and response buffer sizes are not identical");
+ return -EINVAL;
+ }
+
+ priv->rsp = priv->cmd;
+ return 0;
}
static int crb_acpi_add(struct acpi_device *device)
Patches currently in stable-queue which might be from jarkko.sakkinen@xxxxxxxxxxxxxxx are
queue-4.7/tpm_crb-fix-mapping-of-the-buffers.patch
queue-4.7/tpm_crb-drop-struct-resource-res-from-struct-crb_priv.patch
queue-4.7/tpm-fix-byte-order-for-the-value-read-by-tpm2_get_tpm_pt.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html