On Mon, Sep 16, 2019 at 10:35:52AM +0300, Jarkko Sakkinen wrote: > On Sun, Sep 15, 2019 at 11:27:51PM -0400, Mimi Zohar wrote: > > On Sun, 2019-09-15 at 16:52 -0400, Mimi Zohar wrote: > > > On Fri, 2019-09-13 at 15:08 +0100, Jarkko Sakkinen wrote: > > > > On Wed, Sep 11, 2019 at 08:00:40AM -0400, Mimi Zohar wrote: > > > > > On Tue, 2019-09-10 at 19:24 -0400, Mimi Zohar wrote: > > > > > > On Tue, 2019-09-10 at 19:18 -0400, Mimi Zohar wrote: > > > > > > > Create, save and load trusted keys test > > > > > > > > > > > > Creating trusted keys is failing with the following messages. Any idea why? > > > > > > > > > > > > [ 147.014653] tpm tpm0: A TPM error (34) occurred attempting to a send a command > > > > > > [ 147.014678] trusted_key: srkseal failed (-1) > > > > > > [ 147.014687] trusted_key: key_seal failed (-1) > > > > > > > > > > This is a regression, that needs to be resolved. The test works on > > > > > kernels prior to 5.1. > > > > > > > > It breaks on 5.2? > > > > > > No, the regression is in 5.1. > > > > > > > > > > > Can you bisect the failing commit? > > > > > > git bisect start -- drivers/char/tpm/ > > > git bisect bad > > > git bisect good v5.0 > > > > > > # first bad commit: [412eb585587a1dc43c9622db79de9663b6c4c238] tpm: > > > use tpm_buf in tpm_transmit_cmd() as the IO parameter > > > > In tpm_send(), setting buf.data directly to cmd, instead of calling > > tpm_buf_init() fixes the problem. > > I see. Obviously memcpy() does not tpm_buf length. The implementation is > kind of clunky but the point is to move building the tpm_buf to the > caller (which is soon possible thanks to Sumit's patches). > > I sent a fix candidate. Ugh. Sorry about the "fix candidate". Your fix is the way it should be done. I'll put background to it once I've slept a bit. /Jarkko
