From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755432AbdLOLyZ (ORCPT ); Fri, 15 Dec 2017 06:54:25 -0500 Received: from mx3.molgen.mpg.de ([141.14.17.11]:56937 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755222AbdLOLyV (ORCPT ); Fri, 15 Dec 2017 06:54:21 -0500 Subject: Re: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest` To: Mario Limonciello , Alexander Steffen , Jason Gunthorpe Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Len Brown References: <32b0e6c1292f4818825e9e0e9bff4d39@infineon.com> <20171207183743.GB16884@ziepe.ca> <37b47bbcce5d4cf1b1fad32576e501d4@infineon.com> <20171208155641.GA2883@ziepe.ca> <20171208161814.GB2883@ziepe.ca> <3159adc4-4236-c963-a118-500a61f21338@molgen.mpg.de> <10b81a727ba940889095fa4bb29d0863@infineon.com> <5efeaf9e50e54b999efa91c39f311bd9@ausx13mpc120.AMER.DELL.COM> From: Paul Menzel Message-ID: <127aefc5-44e1-7382-2548-5cd4774275b0@molgen.mpg.de> Date: Fri, 15 Dec 2017 12:54:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5efeaf9e50e54b999efa91c39f311bd9@ausx13mpc120.AMER.DELL.COM> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030100090504040107010300" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a cryptographically signed message in MIME format. --------------ms030100090504040107010300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable [Adding Rafael and Len as they, to my knowledge, also use or have a=20 access to a Dell XPS 13 9360. With latest Linux master do you get TPM=20 self-test errors, when cold starting the system without the power supply = plugged in?] Dear Mario, dear Alexander, the added line breaks to the quoted parts really mess up the citation.=20 Can we please try to use MUAs avoiding that, or fixing that manually? On 12/14/17 20:43, Mario.Limonciello@dell.com wrote: >> -----Original Message----- >> From: Alexander.Steffen@infineon.com [mailto:Alexander.Steffen@infineo= n.com] >> Sent: Thursday, December 14, 2017 10:12 AM >> To: Limonciello, Mario ; pmenzel@molgen.mp= g.de; >> jgg@ziepe.ca >> Cc: linux-integrity@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error= (2314) >> occurred continue selftest` >> >>>> -----Original Message----- >>>> From: Alexander.Steffen@infineon.com >>> [mailto:Alexander.Steffen@infineon.com] >>>> Sent: Thursday, December 14, 2017 6:21 AM >>>> To: pmenzel@molgen.mpg.de; jgg@ziepe.ca >>>> Cc: linux-integrity@vger.kernel.org; linux-kernel@vger.kernel.org; >>> Limonciello, >>>> Mario >>>> Subject: RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM err= or >>> (2314) >>>> occurred continue selftest` >>>> >>>>> [Mario from Dell added to CC list.] >>>>> >>>>> Dear Alexander, >>>>> >>>>> >>>>> On 12/11/17 17:08, Alexander.Steffen@infineon.com wrote: >>>>> >>>>>>> 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 mes= ses >>> with >>>>> the >>>>>>>>> time stamps. I checked the output of `dmesg` but didn=E2=80=99t= see the >>> TPM >>>>> error >>>>>>>>> messages in the output =E2=80=93 only `tpm_tis MSFT0101:00: 2.0= TPM >>> (device- >>>>> id 0xFE, >>>>>>>>> rev-id 4)`. Do I need to pass a different error message to `dme= sg`? >>>>>>>> >>>>>>>> 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 r= unning >>>>>>> `dmesg`. Sorry for the noise. Here are the messages with the Linu= x >>>>>>> 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 sel= ftest >>>>>>> [ 1.156645] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 1.208053] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 1.299640] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 1.471223] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 1.802819] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 2.454320] tpm tpm0: A TPM error (2314) occurred continue sel= ftest >>>>>>> [ 3.734808] tpm tpm0: TPM self test failed >>>>>>> [ 3.759675] ima: No TPM chip found, activating TPM-bypass! (rc= =3D-19) >>>>>>> ``` >>>>>> >>>>>> Thanks for the fixed log. So your TPM seems to be rather slow with= >>>>> executing the selftests. Could try to apply the patch that I've jus= t sent >>> you? It >>>>> ensures that your TPM gets more time to execute all the tests, up t= o the >>> limit >>>>> set in the PTP. >>>>> >>>>> Thank you for your patch. Judging from the time stamps, it seems it= >>>>> works, but the TPM still fails. >>>>> >>>>> ``` >>>>> $ dmesg | grep tpm >>>>> [ 1.100958] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id= 4) >>>>> [ 1.111768] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 1.143020] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 1.194251] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 1.285509] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 1.457103] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 1.788709] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 2.440216] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 3.731704] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 6.303216] tpm tpm0: A TPM error (2314) occurred continue selft= est >>>>> [ 6.303242] tpm tpm0: TPM self test failed >>>>> ``` >>>>> >>>>> To be clear, this issue is not reproducible during every start. (Bu= t >>>>> that was the same before.) I think I found out how to reproduce the issue. Cold start the system=20 without the power supply connected. >>>> Thanks for testing. Now you are in the unlucky situation that your T= PM was >>>> probably always broken, but old kernels did not detect that and used= it anyway. Just to clarify, I do not know if the TPM could ever be used. I believe=20 the module loaded but the user space tools (tpm2_version or so) always=20 returned an error in my tests. >>> Something that Paul can consider is to upgrade the TPM firmware if it= 's not >>> already >>> upgraded. Since the launch of XPS 9360 there was at least one TPM fi= rmware >>> update >>> issued. It has been posted to LVFS and can be upgraded using >>> fwupd/fwupdate. >>> Note: If your TPM is currently owned you will need to go into BIOS se= tup to >>> clear it >>> first before upgrading. >> >> I'm not familiar with the specific TPM in your model, but according to= the log it is a >> TPM 2.0, which does not really carry over the owner concept of a TPM 1= =2E2. Is >> clearing it still necessary for an upgrade then? >=20 > Yes it's required for the TPM model/vendor that is used in the XPS mode= l that > Paul has. If you try to run the upgrade without clearing it the firmwa= re will > reject the upgrade. Mario, thank you for your quick reaction. [=E2=80=A6] 1. Can you reproduce this issue too? 2. How do I find out, what TPM firmware version is installed? 3. Updating to the firmware 2.4.2 from December 17th, 2017 didn=E2=80=99= t fix=20 the issue. >>>> To add some more details to what the problem is: The PTP limits the >>> maximum >>>> runtime of the TPM2_SelfTest command that we try to execute here to >>> 2000ms >>>> (see https://trustedcomputinggroup.org/wp- >>>> >>> content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_Specification_= >>> Family >>>> _2.0_Revision_1.3v22.pdf table 15, page 65 in the PDF, page 57 accor= ding to >>> the >>>> printed page numbers). Technically, we have no evidence that your TP= M is >>> in >>>> violation of that specification, because it does reply to the comman= d within >>>> 2000ms, it just has not completed the selftests within that timefram= e. But >>> clearly >>>> the intention of the specification authors was to have the selftests= >>> completed >>>> within that limit, there is no sense in allowing 2s just for the TPM= to >>> generate an >>>> answer without actually making any progress. >>>> >>>> The TPM2_SelfTest command is special in that it is allowed to either= >>> execute all >>>> selftests and then return TPM_RC_SUCCESS or just schedule the selfte= st >>> execution >>>> in the background and return TPM_RC_TESTING immediately (see >>>> https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0- >>> Part-3- >>>> Commands-01.38.pdf chapter 10.2.1, page 43/29). Your TPM apparently >>> chooses >>>> the second option, but (sometimes?) fails to complete the selftests = within >>> the limit >>>> that we set (which is far longer than the 2s from the PTP). >>>> >>>> I'm not sure what to do about that now. We could increase the timeou= t >>> even >>>> further, but if your TPM does not abide by the specification, what w= ould be >>> the >>>> right limit? Maybe there is a bug in your TPM that sometimes causes = it to >>> end up in >>>> a state where it can never complete the selftests. >>> >>> Are there any representatives from the other TPM vendors on the linux= - >>> integrrity >>> mailing list? Maybe someone from the vendor involved in this laptop = can >>> comment >>> if they know of limitations in the self tests on this particular mode= l and can >>> recommend a solution. >>> >>>> >>>> The only other idea I have would be to use a different variant of th= e >>> TPM2_SelfTest >>>> command. Currently, we execute the selftest command with the >>> parameter >>>> fullTest=3DNO, so that the TPM only has to execute the missing tests= (which >>> should be >>>> the fastest implementation for a spec-compliant TPM). Maybe instead = of >>> giving up, >>>> we can extend the current algorithm to try fullTest=3DYES once, whic= h should >>> reset >>>> the selftest state so that maybe then your TPM can complete them >>> successfully. I'll >>>> try to implement a patch to that effect. >>> >>> If you're fairly certain it's a TPM bug, another possibility is to qu= irk to skip self >>> tests >>> based on TPM model + TPM firmware version. >> >> As a last resort maybe, yes. But currently the kernel's policy is that= it only wants to >> talk to a TPM device that is guaranteed to be error-free, i.e. has exe= cuted the >> selftests correctly. I'd like to change that for other reasons (see th= e patches that I >> just posted for details), but now that you mention it, maybe there is = a simple >> solution that solves both problems: >> >> The TPM specification says "If a command requires use of an untested a= lgorithm or >> functional module, the TPM performs the test and then completes the co= mmand >> actions." (https://trustedcomputinggroup.org/wp-content/uploads/TPM-Re= v-2.0- >> Part-1-Architecture-01.38.pdf chapter 12.3, page 83/59). So as far as = I understand >> that, there is no need for us to explicitly execute selftests on any T= PM (2.0) device, >> the TPM is required to do that automatically. So what about getting ri= d of the >> selftest call completely? >> >> It will improve startup performance, because we do not have to wait fo= r the TPM to >> complete all selftests. The worst case is that the first execution of = a command >> requiring a specific functionality will be a bit slower, because the T= PM has to do the >> selftests first. But maybe even that won't be the case, since the same= chapter in the >> specification also says "It is preferable for the TPM to perform self-= tests on >> untested algorithms and functional blocks as a background task to incr= ease the >> likelihood that algorithms are tested before they are needed." >> >> The only disadvantage I can see from a user's point of view is that he= will discover a >> broken TPM device only when he tries to use it, not already when the k= ernel tries to >> load the driver. But that also applies to other devices, you will not = notice a broken >> flash drive unless you try to access the data, not from just plugging = it in. And if a >> user really cares, he is always free to execute TPM2_SelfTest via /dev= /tpm*. Any >> other objections? >=20 > Your logic to this idea sounds good to me. The only potential problem = would be if > the kernel were ever to directly use the TPM for storing data. It perh= aps might hit > this at an inopportune time. > Otherwise no objections from my side, but I'm no decision maker in this= area. Kind regards, Paul --------------ms030100090504040107010300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EFowggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWNMIIEdaADAgECAgwcOtRQhH7u81j4jncwDQYJKoZIhvcNAQELBQAwgZUx CzAJBgNVBAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1 dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNV BAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjAeFw0xNjExMDMxNTI0 NDhaFw0zMTAyMjIyMzU5NTlaMGoxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCE11ZW5jaGVuMSAwHgYDVQQKDBdNYXgtUGxhbmNrLUdlc2VsbHNjaGFmdDEVMBMG A1UEAwwMTVBHIENBIC0gRzAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnhx4 59Lh4WqgOs/Md04XxU2yFtfM15ZuJV0PZP7BmqSJKLLPyqmOrADfNdJ5PIGBto2JBhtRRBHd G0GROOvTRHjzOga95WOTeura79T21FWwwAwa29OFnD3ZplQs6HgdwQrZWNi1WHNJxn/4mA19 rNEBUc5urSIpZPvZi5XmlF3v3JHOlx3KWV7mUteB4pwEEfGTg4npPAJbp2o7arxQdoIq+Pu2 OsvqhD7Rk4QeaX+EM1QS4lqd1otW4hE70h/ODPy1xffgbZiuotWQLC6nIwa65Qv6byqlIX0q Zuu99Vsu+r3sWYsL5SBkgecNI7fMJ5tfHrjoxfrKl/ErTAt8GQIDAQABo4ICBTCCAgEwEgYD VR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0gBCIwIDANBgsrBgEEAYGt IYIsHjAPBg0rBgEEAYGtIYIsAQEEMB0GA1UdDgQWBBTEiKUH7rh7qgwTv9opdGNSG0lwFjAf BgNVHSMEGDAWgBST49gyJtrV8UqlkUrg6kviogzP4TCBjwYDVR0fBIGHMIGEMECgPqA8hjpo dHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWcyLWNhL3B1Yi9jcmwvY2Fjcmwu Y3JsMECgPqA8hjpodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWcyLWNhL3B1 Yi9jcmwvY2FjcmwuY3JsMIHdBggrBgEFBQcBAQSB0DCBzTAzBggrBgEFBQcwAYYnaHR0cDov L29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEoGCCsGAQUFBzAChj5odHRwOi8v Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWcyLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1j YS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBABLpeD5FygzqOjj+ /lAOy20UQOGWlx0RMuPcI4nuyFT8SGmK9lD7QCg/HoaJlfU/r78ex+SEide326evlFAoJXIF jVyzNltDhpMKrPIDuh2N12zyn1EtagqPL6hu4pVRzcBpl/F2HCvtmMx5K4WN1L1fmHWLcSap dhXLvAZ9RG/B3rqyULLSNN8xHXYXpmtvG0VGJAndZ+lj+BH7uvd3nHWnXEHC2q7iQlDUqg0a wIqWJgdLlx1Q8Dg/sodv0m+LN0kOzGvVDRCmowBdWGhhusD+duKV66pBl+qhC+4LipariWaM qK5ppMQROATjYeNRvwI+nDcEXr2vDaKmdbxgDVwwggWvMIIEl6ADAgECAgweKlJIhfynPMVG /KIwDQYJKoZIhvcNAQELBQAwajELMAkGA1UEBhMCREUxDzANBgNVBAgMBkJheWVybjERMA8G A1UEBwwITXVlbmNoZW4xIDAeBgNVBAoMF01heC1QbGFuY2stR2VzZWxsc2NoYWZ0MRUwEwYD VQQDDAxNUEcgQ0EgLSBHMDIwHhcNMTcxMTE0MTEzNDE2WhcNMjAxMTEzMTEzNDE2WjCBizEL MAkGA1UEBhMCREUxIDAeBgNVBAoMF01heC1QbGFuY2stR2VzZWxsc2NoYWZ0MTQwMgYDVQQL DCtNYXgtUGxhbmNrLUluc3RpdHV0IGZ1ZXIgbW9sZWt1bGFyZSBHZW5ldGlrMQ4wDAYDVQQL DAVNUElNRzEUMBIGA1UEAwwLUGF1bCBNZW56ZWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDIh/UR/AX/YQ48VWWDMLTYtXjYJyhRHMc81ZHMMoaoG66lWB9MtKRTnB5lovLZ enTIUyPsCrMhTqV9CWzDf6v9gOTWVxHEYqrUwK5H1gx4XoK81nfV8oGV4EKuVmmikTXiztGz peyDmOY8o/EFNWP7YuRkY/lPQJQBeBHYq9AYIgX4StuXu83nusq4MDydygVOeZC15ts0tv3/ 6WmibmZd1OZRqxDOkoBbY3Djx6lERohs3IKS6RKiI7e90rCSy9rtidJBOvaQS9wvtOSKPx0a +2pAgJEVzZFjOAfBcXydXtqXhcpOi2VCyl+7+LnnTz016JJLsCBuWEcB3kP9nJYNAgMBAAGj ggIxMIICLTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFHM0Mc3XjMLlhWpp4JufRELL4A/qMB8GA1UdIwQYMBaA FMSIpQfuuHuqDBO/2il0Y1IbSXAWMCAGA1UdEQQZMBeBFXBtZW56ZWxAbW9sZ2VuLm1wZy5k ZTB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY2RwMS5wY2EuZGZuLmRlL21wZy1nMi1jYS9w dWIvY3JsL2NhY3JsLmNybDA4oDagNIYyaHR0cDovL2NkcDIucGNhLmRmbi5kZS9tcGctZzIt Y2EvcHViL2NybC9jYWNybC5jcmwwgc0GCCsGAQUFBwEBBIHAMIG9MDMGCCsGAQUFBzABhido dHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbXBnLWcyLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBC BggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNhLmRmbi5kZS9tcGctZzItY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEAGA1UdIAQ5MDcwDwYNKwYBBAGBrSGCLAEBBDARBg8rBgEEAYGtIYIs AQEEAwYwEQYPKwYBBAGBrSGCLAIBBAMGMA0GCSqGSIb3DQEBCwUAA4IBAQCQs6bUDROpFO2F Qz2FMgrdb39VEo8P3DhmpqkaIMC5ZurGbbAL/tAR6lpe4af682nEOJ7VW86ilsIJgm1j0ueY aOuL8jrN4X7IF/8KdZnnNnImW3QVni6TCcc+7+ggci9JHtt0IDCj5vPJBpP/dKXLCN4M+exl GXYpfHgxh8gclJPY1rquhQrihCzHfKB01w9h9tWZDVMtSoy9EUJFhCXw7mYUsvBeJwZesN2B fndPkrXx6XWDdU3S1LyKgHlLIFtarLFm2Hb5zAUR33h+26cN6ohcGqGEEzgIG8tXS8gztEaj 1s2RyzmKd4SXTkKR3GhkZNVWy+gM68J7jP6zzN+cMYIDmjCCA5YCAQEwejBqMQswCQYDVQQG EwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhNdWVuY2hlbjEgMB4GA1UECgwXTWF4 LVBsYW5jay1HZXNlbGxzY2hhZnQxFTATBgNVBAMMDE1QRyBDQSAtIEcwMgIMHipSSIX8pzzF RvyiMA0GCWCGSAFlAwQCAQUAoIIB8TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzEyMTUxMTU0MThaMC8GCSqGSIb3DQEJBDEiBCDk7VjY4otzCF6EDfpU w1MRKyXMraa1f6x4Jy1DF9tkXjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGJBgkrBgEEAYI3EAQxfDB6MGoxCzAJBgNVBAYTAkRF MQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcMCE11ZW5jaGVuMSAwHgYDVQQKDBdNYXgtUGxh bmNrLUdlc2VsbHNjaGFmdDEVMBMGA1UEAwwMTVBHIENBIC0gRzAyAgweKlJIhfynPMVG/KIw gYsGCyqGSIb3DQEJEAILMXygejBqMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREw DwYDVQQHDAhNdWVuY2hlbjEgMB4GA1UECgwXTWF4LVBsYW5jay1HZXNlbGxzY2hhZnQxFTAT BgNVBAMMDE1QRyBDQSAtIEcwMgIMHipSSIX8pzzFRvyiMA0GCSqGSIb3DQEBAQUABIIBACEs OqR/DgQEBS1BjiMsok61c3AOm4PzflqqLwfsaxlqajRxzz4k0MzsUHp8TyPMmdkFoYSix7oV qE1+cuezzkjTAzxfWMiy0DgPsM1aaqru81DQWP7ov1CKaWfWZZmquOEAvaFxyhCndZomqTpd ltTl9VVy2lB1K/rPQ9J1sbFYi+l54djwCCh2QyV3tNpf/w3gYhjnDt0Vzp8CFOVi1coYNFQ6 SSlDZuta1tv+aOiiczYjnLnp3Mpxtar7JIC5rmz6z+Y7W0byfBP0yi7ZlpSoWXfVRsrBkFY1 86rDjnrll8RsWE9iFh06ZXfvzD0UM/a8qQDJhoN0NTPEhtRsgV8AAAAAAAA= --------------ms030100090504040107010300-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3.molgen.mpg.de ([141.14.17.11]:56937 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755222AbdLOLyV (ORCPT ); Fri, 15 Dec 2017 06:54:21 -0500 Subject: Re: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest` To: Mario Limonciello , Alexander Steffen , Jason Gunthorpe Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Len Brown References: <32b0e6c1292f4818825e9e0e9bff4d39@infineon.com> <20171207183743.GB16884@ziepe.ca> <37b47bbcce5d4cf1b1fad32576e501d4@infineon.com> <20171208155641.GA2883@ziepe.ca> <20171208161814.GB2883@ziepe.ca> <3159adc4-4236-c963-a118-500a61f21338@molgen.mpg.de> <10b81a727ba940889095fa4bb29d0863@infineon.com> <5efeaf9e50e54b999efa91c39f311bd9@ausx13mpc120.AMER.DELL.COM> From: Paul Menzel Message-ID: <127aefc5-44e1-7382-2548-5cd4774275b0@molgen.mpg.de> Date: Fri, 15 Dec 2017 12:54:18 +0100 MIME-Version: 1.0 In-Reply-To: <5efeaf9e50e54b999efa91c39f311bd9@ausx13mpc120.AMER.DELL.COM> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030100090504040107010300" Sender: linux-integrity-owner@vger.kernel.org List-ID: [Adding Rafael and Len as they, to my knowledge, also use or have a access to a Dell XPS 13 9360. With latest Linux master do you get TPM self-test errors, when cold starting the system without the power supply plugged in?] Dear Mario, dear Alexander, the added line breaks to the quoted parts really mess up the citation. Can we please try to use MUAs avoiding that, or fixing that manually? On 12/14/17 20:43, Mario.Limonciello@dell.com wrote: >> -----Original Message----- >> From: Alexander.Steffen@infineon.com [mailto:Alexander.Steffen@infineon.com] >> Sent: Thursday, December 14, 2017 10:12 AM >> To: Limonciello, Mario ; pmenzel@molgen.mpg.de; >> jgg@ziepe.ca >> Cc: linux-integrity@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) >> occurred continue selftest` >> >>>> -----Original Message----- >>>> From: Alexander.Steffen@infineon.com >>> [mailto:Alexander.Steffen@infineon.com] >>>> Sent: Thursday, December 14, 2017 6:21 AM >>>> To: pmenzel@molgen.mpg.de; jgg@ziepe.ca >>>> Cc: linux-integrity@vger.kernel.org; linux-kernel@vger.kernel.org; >>> Limonciello, >>>> Mario >>>> Subject: RE: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error >>> (2314) >>>> occurred continue selftest` >>>> >>>>> [Mario from Dell added to CC list.] >>>>> >>>>> Dear Alexander, >>>>> >>>>> >>>>> On 12/11/17 17:08, Alexander.Steffen@infineon.com wrote: >>>>> >>>>>>> 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) >>>>>>> ``` >>>>>> >>>>>> Thanks for the fixed log. So your TPM seems to be rather slow with >>>>> executing the selftests. Could try to apply the patch that I've just sent >>> you? It >>>>> ensures that your TPM gets more time to execute all the tests, up to the >>> limit >>>>> set in the PTP. >>>>> >>>>> Thank you for your patch. Judging from the time stamps, it seems it >>>>> works, but the TPM still fails. >>>>> >>>>> ``` >>>>> $ dmesg | grep tpm >>>>> [ 1.100958] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4) >>>>> [ 1.111768] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 1.143020] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 1.194251] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 1.285509] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 1.457103] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 1.788709] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 2.440216] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 3.731704] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 6.303216] tpm tpm0: A TPM error (2314) occurred continue selftest >>>>> [ 6.303242] tpm tpm0: TPM self test failed >>>>> ``` >>>>> >>>>> To be clear, this issue is not reproducible during every start. (But >>>>> that was the same before.) I think I found out how to reproduce the issue. Cold start the system without the power supply connected. >>>> Thanks for testing. Now you are in the unlucky situation that your TPM was >>>> probably always broken, but old kernels did not detect that and used it anyway. Just to clarify, I do not know if the TPM could ever be used. I believe the module loaded but the user space tools (tpm2_version or so) always returned an error in my tests. >>> Something that Paul can consider is to upgrade the TPM firmware if it's not >>> already >>> upgraded. Since the launch of XPS 9360 there was at least one TPM firmware >>> update >>> issued. It has been posted to LVFS and can be upgraded using >>> fwupd/fwupdate. >>> Note: If your TPM is currently owned you will need to go into BIOS setup to >>> clear it >>> first before upgrading. >> >> I'm not familiar with the specific TPM in your model, but according to the log it is a >> TPM 2.0, which does not really carry over the owner concept of a TPM 1.2. Is >> clearing it still necessary for an upgrade then? > > Yes it's required for the TPM model/vendor that is used in the XPS model that > Paul has. If you try to run the upgrade without clearing it the firmware will > reject the upgrade. Mario, thank you for your quick reaction. [...] 1. Can you reproduce this issue too? 2. How do I find out, what TPM firmware version is installed? 3. Updating to the firmware 2.4.2 from December 17th, 2017 didn't fix the issue. >>>> To add some more details to what the problem is: The PTP limits the >>> maximum >>>> runtime of the TPM2_SelfTest command that we try to execute here to >>> 2000ms >>>> (see https://trustedcomputinggroup.org/wp- >>>> >>> content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_Specification_ >>> Family >>>> _2.0_Revision_1.3v22.pdf table 15, page 65 in the PDF, page 57 according to >>> the >>>> printed page numbers). Technically, we have no evidence that your TPM is >>> in >>>> violation of that specification, because it does reply to the command within >>>> 2000ms, it just has not completed the selftests within that timeframe. But >>> clearly >>>> the intention of the specification authors was to have the selftests >>> completed >>>> within that limit, there is no sense in allowing 2s just for the TPM to >>> generate an >>>> answer without actually making any progress. >>>> >>>> The TPM2_SelfTest command is special in that it is allowed to either >>> execute all >>>> selftests and then return TPM_RC_SUCCESS or just schedule the selftest >>> execution >>>> in the background and return TPM_RC_TESTING immediately (see >>>> https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0- >>> Part-3- >>>> Commands-01.38.pdf chapter 10.2.1, page 43/29). Your TPM apparently >>> chooses >>>> the second option, but (sometimes?) fails to complete the selftests within >>> the limit >>>> that we set (which is far longer than the 2s from the PTP). >>>> >>>> I'm not sure what to do about that now. We could increase the timeout >>> even >>>> further, but if your TPM does not abide by the specification, what would be >>> the >>>> right limit? Maybe there is a bug in your TPM that sometimes causes it to >>> end up in >>>> a state where it can never complete the selftests. >>> >>> Are there any representatives from the other TPM vendors on the linux- >>> integrrity >>> mailing list? Maybe someone from the vendor involved in this laptop can >>> comment >>> if they know of limitations in the self tests on this particular model and can >>> recommend a solution. >>> >>>> >>>> The only other idea I have would be to use a different variant of the >>> TPM2_SelfTest >>>> command. Currently, we execute the selftest command with the >>> parameter >>>> fullTest=NO, so that the TPM only has to execute the missing tests (which >>> should be >>>> the fastest implementation for a spec-compliant TPM). Maybe instead of >>> giving up, >>>> we can extend the current algorithm to try fullTest=YES once, which should >>> reset >>>> the selftest state so that maybe then your TPM can complete them >>> successfully. I'll >>>> try to implement a patch to that effect. >>> >>> If you're fairly certain it's a TPM bug, another possibility is to quirk to skip self >>> tests >>> based on TPM model + TPM firmware version. >> >> As a last resort maybe, yes. But currently the kernel's policy is that it only wants to >> talk to a TPM device that is guaranteed to be error-free, i.e. has executed the >> selftests correctly. I'd like to change that for other reasons (see the patches that I >> just posted for details), but now that you mention it, maybe there is a simple >> solution that solves both problems: >> >> The TPM specification says "If a command requires use of an untested algorithm or >> functional module, the TPM performs the test and then completes the command >> actions." (https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0- >> Part-1-Architecture-01.38.pdf chapter 12.3, page 83/59). So as far as I understand >> that, there is no need for us to explicitly execute selftests on any TPM (2.0) device, >> the TPM is required to do that automatically. So what about getting rid of the >> selftest call completely? >> >> It will improve startup performance, because we do not have to wait for the TPM to >> complete all selftests. The worst case is that the first execution of a command >> requiring a specific functionality will be a bit slower, because the TPM has to do the >> selftests first. But maybe even that won't be the case, since the same chapter in the >> specification also says "It is preferable for the TPM to perform self-tests on >> untested algorithms and functional blocks as a background task to increase the >> likelihood that algorithms are tested before they are needed." >> >> The only disadvantage I can see from a user's point of view is that he will discover a >> broken TPM device only when he tries to use it, not already when the kernel tries to >> load the driver. But that also applies to other devices, you will not notice a broken >> flash drive unless you try to access the data, not from just plugging it in. And if a >> user really cares, he is always free to execute TPM2_SelfTest via /dev/tpm*. Any >> other objections? > > Your logic to this idea sounds good to me. The only potential problem would be if > the kernel were ever to directly use the TPM for storing data. It perhaps might hit > this at an inopportune time. > Otherwise no objections from my side, but I'm no decision maker in this area. Kind regards, Paul [ Part 2, "S/MIME Cryptographic Signature" ] [ Application/PKCS7-SIGNATURE (Name: "smime.p7s") 5.3 KB. ] [ Unable to print this part. ]