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:   Fri, 6 Apr 2018 13:31:01 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     linux-integrity@...r.kernel.org
Cc:     linux-security-module@...r.kernel.org,
        Jason Gunthorpe <jgg@...pe.ca>,
        open list <linux-kernel@...r.kernel.org>,
        tomas.winkler@...el.com,
        James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [PATCH v4 0/4] Migrate all TPM 2.0 commands to use struct tpm_buf

On Mon, Mar 26, 2018 at 03:14:02PM +0300, Jarkko Sakkinen wrote:
> In order to make struct tpm_buf the first class object for constructing TPM
> commands, this patch set migrates all TPM 2.0 commands to use it. Eventually,
> tpm_transmit_cmd() can take simply struct tpm_buf as its argument and this
> interface can be exported to be used by the kernel keyring and potentially
> other subsystems.
> 
> The ultimate goal of this work is to make constructing TPM commands inside
> the kernel simple and robust.

I pushed these commits to the master branch. Please report if you have
any issues. If the master branch continues working for you, as you test
it maybe for other reasons, I'm happy to get tested-by's for them. At
worst they have regressions. I seriously don't think that the code
changes have any major structural issues.

I would guess that Tomas' similar changes for TPM 1.x will follow at
some point. I'm looking forward to change the existing tpm_send()
as one that takes tpm_buf in. That will allow to remove a lot of
cruft code from keyring.

I take no rush to merge these to 'next' but I think it is fine to
have these in the bleeding edge.

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ