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: <20190121123739.GD9423@linux.intel.com>
Date:   Mon, 21 Jan 2019 14:37:39 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>
Cc:     zohar@...ux.ibm.com, david.safford@...com, monty.wiseman@...com,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, silviu.vlasceanu@...wei.com,
        Matthew Garrett <matthewgarrett@...gle.com>
Subject: Re: [PATCH v7 5/5] tpm: pass an array of tpm_extend_digest
 structures to tpm_pcr_extend()

On Mon, Jan 21, 2019 at 10:58:22AM +0100, Roberto Sassu wrote:
> Agreed, there should be a clear division.
> 
> 1) The caller shouldn't need to know anything about the chip->info.
> 2) The TPM driver should not rely on the caller to supply all the
> hashes, but verify that all allocated banks are being extended.

1. It is just plain wrong if the basic extend function
   invents its own dummy hashes when it doesn't get one. In the end,
   this is what matters to me, and I'm not going to accept anything that
   tries to do that. That is something that caller should prepare.

   You even left undocumented this very awkward and unguessable
   behaviour. I think redundancy is better than doing guesswork what
   a function might possibly do other than its basic task, which is
   constructing the extend command.
2. The driver should return -EINVAL, if it doesn't get all the hashes.
3. The would be nothing wrong exposing struct tpm_chip in
   include/linux/tpm.h. I would be totally fine with that.

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ