On 26 January 2018 at 18:49, Stefan Berger <stef...@linux.vnet.ibm.com> wrote:
> The patches in this pull request fix a bug in the initialization of
> a variable, adapt the cancel path used by the passthrough device to the
> sysfs path of more recent versions of the Linux kernel, and do some other
> cleanups preparing for support of migration. Finally, we add the CRB
> interface emulation, which is used with a TPM 2.
>
> Stefan
>
> The following changes since commit 0f79bfe38a2cf0f43c7ea4959da7f8ebd7858f3d:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-2.12-pull-request' into staging
> (2018-01-25 09:53:53 +0000)
>
> are available in the git repository at:
>
> git://github.com/stefanberger/qemu-tpm.git tags/pull-tpm-2018-01-26-1
>
> for you to fetch changes up to b510b21e072a0a9218f37051c885e95824d06bea:
>
> tpm: add CRB device (2018-01-26 10:12:02 -0500)
>
> ----------------------------------------------------------------
> Merge tpm 2018/01/26 v1
>
> ----------------------------------------------------------------
Hi. The new tpm-crb-test fails on sparc host:
TEST: tests/tpm-crb-test... (pid=230409)
/i386/tpm-crb/test:
Broken pipe
FAIL
GTester: last random seed: R02S29cea50247fe1efa59ee885a26d51a85
(pid=230423)
FAIL: tests/tpm-crb-test
and generates a new clang sanitizer runtime warning:
/home/petmay01/linaro/qemu-for-merges/hw/tpm/tpm_util.h:36:24: runtime
error: load of misaligned address 0x7fdc24c00002 for type 'const
uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment
0x7fdc24c00002: note: pointer points here
<memory cannot be printed>
Chances are good these are the same thing, because the sparc architecture
does not allow misaligned loads and will segfault if you try them.
This function looks like it's the immediate culprit:
static inline uint32_t tpm_cmd_get_size(const void *b)
{
return be32_to_cpu(*(const uint32_t *)(b + 2));
}
I suspect that this function should read
return ldl_be_p(b + 2);
This is likely not the only problem with misaligned data in the
tpm code -- for instance the cast here in tpm_util_is_selftest()
looks odd:
bool tpm_util_is_selftest(const uint8_t *in, uint32_t in_len)
{
struct tpm_req_hdr *hdr = (struct tpm_req_hdr *)in;
As a general rule you can't take an arbitrary pointer into a byte
buffer and try to interpret it as a structure or a pointer to
a larger-than-bytesize-data simply by casting the pointer.
It might be worth reviewing all the tpm code for bugs
of this nature.
thanks
-- PMM
