linux-kernel - Re: [PATCH v2] tpm_crb: request and relinquish locality 0

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] [day] [month] [year] [list]

Date:   Mon, 13 Mar 2017 14:43:14 -0600
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     tpmdd-devel@...ts.sourceforge.net,
        linux-security-module@...r.kernel.org,
        Jerry Snitselaar <jsnitsel@...hat.com>, gang.wei@...el.com,
        Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] tpm_crb: request and relinquish locality 0

On Mon, Mar 13, 2017 at 10:12:35PM +0200, Jarkko Sakkinen wrote:
> > I think you should also put a relinquish_locality inside tpm_remove ?
> 
> Right. I was wondering why release_locality is called inside
> tpm_tis_remove().

I also wonder that.. It sort of makes send to idle the TPM, but it is
kinda goofy to have paired function calls that are not ultimately
paried.

> So is the idea of checking pendingRequest such that the release
> part is "lazy" and not like what I'm doing in tpm_crb (always
> relinquish).
>
> Is that done for performance reasons? Should I do the same (pr
> similar in tpm_crb?

No idea, sorry. This stuff is so old and locality has never been an
exposed API by the kernel, AFAIK. Wouldn't surprise me at all if it
doesn't work right.

But.. If you don't need 'force' for CRB, I suggest that we drop the
'force' from the public API. TIS can do its special !force behavior in
its own remove as it does today.

However.. if we want to do some kind of locality caching for
performance then I think the core code should do it, not the
individual drivers.

Why do we need to reliquish the locality on every command anyhow? Does
the firmware interact with this?

Why are you adding locality to crb without a user anyhow?

Jason