Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1224355 > unrolled thread

[PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

Back to article view | Back to linux.kernel

Contents

  [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2015-09-14 19:20 +0200
    Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer  address Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-09-14 19:40 +0200
      Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer  address Jarkko Sakkinen <jarkko.sakkinen@intel.com> - 2015-09-15 12:20 +0200
        Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer  address Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-09-15 18:40 +0200
          Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer  address Jarkko Sakkinen <jarkko.sakkinen@intel.com> - 2015-09-15 18:50 +0200

#1224355 — [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

The command buffer address is necessarily not naturally aligned.
The hardware drops the entire read on some platforms and fills the
address with 1's. This patch fixes the issue by splitting the read
into two 32 bit reads.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 drivers/char/tpm/tpm_crb.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index b4564b6..12bb41c 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -68,7 +68,8 @@ struct crb_control_area {
 	u32 int_enable;
 	u32 int_sts;
 	u32 cmd_size;
-	u64 cmd_pa;
+	u32 cmd_pa_low;
+	u32 cmd_pa_high;
 	u32 rsp_size;
 	u64 rsp_pa;
 } __packed;
@@ -264,7 +265,9 @@ static int crb_acpi_add(struct acpi_device *device)
 	}
 
 	memcpy_fromio(&pa, &priv->cca->cmd_pa, 8);
-	pa = le64_to_cpu(pa);
+
+	pa = ((u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_high)) << 32) +
+		(u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_low));
 	priv->cmd = devm_ioremap_nocache(dev, pa,
 					 ioread32(&priv->cca->cmd_size));
 	if (!priv->cmd) {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1224368 — Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

On Mon, Sep 14, 2015 at 08:15:23PM +0300, Jarkko Sakkinen wrote:
> The command buffer address is necessarily not naturally aligned.
> The hardware drops the entire read on some platforms and fills the
> address with 1's. This patch fixes the issue by splitting the read
> into two 32 bit reads.

Is this necessary? The packed attribution means that unaligned members
are allowed and the compiler deals with it where necessary.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224975 — Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

On Mon, Sep 14, 2015 at 11:35:23AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 14, 2015 at 08:15:23PM +0300, Jarkko Sakkinen wrote:
> > The command buffer address is necessarily not naturally aligned.
> > The hardware drops the entire read on some platforms and fills the
> > address with 1's. This patch fixes the issue by splitting the read
> > into two 32 bit reads.
> 
> Is this necessary? The packed attribution means that unaligned members
> are allowed and the compiler deals with it where necessary.

For regular memory memory controller splits the read into two 32 bit
reads.

However, for MMIO address the hardware might abort the entire request
when trying to do a 64-bit read, which causes the CPU to fill the result
with 1's.

This is not hypothetical bug. We are experiencing this on some platforms
and the proposed fix resolves the issue.

> Jason

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225400 — Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

On Tue, Sep 15, 2015 at 01:09:56PM +0300, Jarkko Sakkinen wrote:
> However, for MMIO address the hardware might abort the entire request
> when trying to do a 64-bit read, which causes the CPU to fill the result
> with 1's.

Okay, yes, for iomem you can't rely on packed.

packed actually can mess up iomem loads on some arches as it also
tells the compiler things are unaligned. I'd drop the __packed since
the new structure is naturally packed in this case. (for other cases
be careful to add __aligned(2) to avoid unaligned accesses)

However, I'm still confused, the original code did:
 	memcpy_fromio(&pa, &priv->cca->cmd_pa, 8);

Which might do byte reads from the iomem cmd_pa, but there should be
no problem with an unaligned access.

Is the real issue that you can't do memcpy_fromio to tpm control
memory? That would not suprise me one bit. In which case the commit
message should be revised.

> This is not hypothetical bug. We are experiencing this on some platforms
> and the proposed fix resolves the issue.

I am confused because of the memcpy_fromio:

 	memcpy_fromio(&pa, &priv->cca->cmd_pa, 8);
-	pa = le64_to_cpu(pa);
+
+	pa = ((u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_high)) << 32) +
+		(u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_low));
 	priv->cmd = devm_ioremap_nocache(dev, pa,
 					 ioread32(&priv->cca->cmd_size));

The code wasn't doing a direct load from cmd_pa, so the type doesn't
matter.

BTW. Does the above even compile with that memcpy_fromio left in?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225411 — Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

On Tue, Sep 15, 2015 at 10:30:39AM -0600, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2015 at 01:09:56PM +0300, Jarkko Sakkinen wrote:
> > However, for MMIO address the hardware might abort the entire request
> > when trying to do a 64-bit read, which causes the CPU to fill the result
> > with 1's.
> 
> Okay, yes, for iomem you can't rely on packed.
> 
> packed actually can mess up iomem loads on some arches as it also
> tells the compiler things are unaligned. I'd drop the __packed since
> the new structure is naturally packed in this case. (for other cases
> be careful to add __aligned(2) to avoid unaligned accesses)
> 
> However, I'm still confused, the original code did:
>  	memcpy_fromio(&pa, &priv->cca->cmd_pa, 8);
> 
> Which might do byte reads from the iomem cmd_pa, but there should be
> no problem with an unaligned access.
> 
> Is the real issue that you can't do memcpy_fromio to tpm control
> memory? That would not suprise me one bit. In which case the commit
> message should be revised.

Good question and point. Emprically it seems to be so. I guess you
have to do exactly 32-bit read for the field. I'll revise the commit
message.

> > This is not hypothetical bug. We are experiencing this on some platforms
> > and the proposed fix resolves the issue.
> 
> I am confused because of the memcpy_fromio:
> 
>  	memcpy_fromio(&pa, &priv->cca->cmd_pa, 8);
> -	pa = le64_to_cpu(pa);
> +
> +	pa = ((u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_high)) << 32) +
> +		(u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_low));
>  	priv->cmd = devm_ioremap_nocache(dev, pa,
>  					 ioread32(&priv->cca->cmd_size));
> 
> The code wasn't doing a direct load from cmd_pa, so the type doesn't
> matter.
> 
> BTW. Does the above even compile with that memcpy_fromio left in?

Nope :) See my own reply to the original message.

> Jason

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web