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]
Message-ID: <6d1441dad4bd41f3a680eac850e099e5@infineon.com>
Date:   Fri, 22 Dec 2017 14:00:56 +0000
From:   <Alexander.Steffen@...ineon.com>
To:     <zohar@...ux.vnet.ibm.com>, <pmenzel@...gen.mpg.de>, <jgg@...pe.ca>
CC:     <linux-integrity@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314)
 occurred continue selftest`

> Hi Paul,
> 
> On Mon, 2017-12-11 at 13:54 +0100, Paul Menzel wrote:
> > Dear Jason,
> >
> >
> > On 12/08/17 17:18, Jason Gunthorpe wrote:
> > > On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote:
> > >
> > >> I have no access to the system right now, but want to point out, that the
> > >> log was created by `journactl -k`, so I do not know if that messes with
> the
> > >> time stamps. I checked the output of `dmesg` but didn’t see the TPM
> error
> > >> messages in the output – only `tpm_tis MSFT0101:00: 2.0 TPM (device-id
> 0xFE,
> > >> rev-id 4)`. Do I need to pass a different error message to `dmesg`?
> > >
> > > It is a good question, I don't know.. If your kernel isn't setup to
> > > timestamp messages then the journalstamp will certainly be garbage.
> > >
> > > No idea why you wouldn't see the messages in dmesg, if they are not in
> > > dmesg they couldn't get into the journal
> >
> > It looks like I was running an older Linux kernel version, when running
> > `dmesg`. Sorry for the noise. Here are the messages with the Linux
> > kernel time stamps, showing that the delays work correctly.
> >
> > ```
> > $ uname -a
> > Linux Ixpees 4.15.0-041500rc2-generic #201712031230 SMP Sun Dec 3
> > 17:32:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> > $ sudo dmesg | grep TPM
> > [    0.000000] ACPI: TPM2 0x000000006F332168 000034 (v03        Tpm2Tabl
> > 00000001 AMI  00000000)
> > [    1.114355] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
> > [    1.125250] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    1.156645] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    1.208053] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    1.299640] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    1.471223] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    1.802819] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    2.454320] tpm tpm0: A TPM error (2314) occurred continue selftest
> > [    3.734808] tpm tpm0: TPM self test failed
> > [    3.759675] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
> > ```
> 
> I've sort of been following this thread, but just want to make sure
> that once the self test is/was fixed, that you aren't seeing the IMA
> message.
> 
> Assuming this is fixed, could someone provide the commit that fixes
> it?

I don't think we've found a solution yet. There might be a firmware upgrade that changes that TPM's behavior. Or maybe my latest patch helps? https://patchwork.kernel.org/patch/10130535/

Alexander

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ