linux-kernel - Re: [PATCH v3 0/2] tpm: add support for nonblocking operation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <279e1857-dbed-808d-0481-ced43f7fa64b@intel.com>
Date:   Thu, 21 Jun 2018 09:20:38 -0700
From:   Tadeusz Struk <tadeusz.struk@...el.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Tadeusz Struk <tstruk@...il.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     jgg@...pe.ca, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, philip.b.tricca@...el.com,
        "Dock, Deneen T" <deneen.t.dock@...el.com>
Subject: Re: [PATCH v3 0/2] tpm: add support for nonblocking operation

On 06/20/2018 10:26 PM, James Bottomley wrote:
>> Yes, it does polling:
>> http://docs.libuv.org/en/v1.x/design.html#the-i-o-loop
> But that's for networking.  You'll be talking to the TPM RM over the
> file descriptor so that follows the thread pool model in
> 
> http://docs.libuv.org/en/v1.x/design.html#file-i-o
> 
> This precisely describes the current file descriptor abstraction we'd
> use for the TPM.

That is for the file IO that doesn't support non-blocking, because there
is no need for it as the operations are "fast".
Operations on the TPM would fall under the io loop model.

> 
>> Regardless of how it actually might be used, I'm happy that we agree
>> on that this *is* the right thing to do.
> I didn't say that.  I think using a single worker thread queue is the
> correct abstraction for the TPM.  If there's a legacy use case for
> poll(), I don't see why not since the code seems to be fairly small and
> self contained, but I don't really see it as correct or necessary to do
> it that way.

This discussion starts to go around the circle. You don't agree, but you
also don't disagree? Is this what you are saying?
Thanks,
-- 
Tadeusz