linux-kernel - Re: [PATCH] tpm, tpm_crb: fix unaligned read of the command buffer address

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]

Date:	Tue, 15 Sep 2015 10:30:39 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Jarkko Sakkinen <jarkko.sakkinen@...el.com>
Cc:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Peter Huewe <peterhuewe@....de>,
	Marcel Selhorst <tpmdd@...horst.net>
Subject: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/