From: Andy Lutomirski <luto@amacapital.net>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: keyrings@linux-nfs.org, jarkko.sakkinnen@linux.intel.com,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
tpmdd-devel@lists.sourceforge.net,
James Morris <james.l.morris@oracle.com>,
linux-ima-devel@lists.sourceforge.net,
trousers-tech@lists.sourceforge.net
Subject: Re: [Ksummit-discuss] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe
Date: Tue, 7 Oct 2014 10:58:27 -0700 [thread overview]
Message-ID: <CALCETrWoAkYTjetqm1e9zYGvetEhn0WQL5poLWv_saQktcHu7g@mail.gmail.com> (raw)
In-Reply-To: <543428E1.7050702@linux.vnet.ibm.com>
On Tue, Oct 7, 2014 at 10:54 AM, Stefan Berger
<stefanb@linux.vnet.ibm.com> wrote:
> On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
>>
>> On Sep 22, 2014 2:07 AM, "Peter Huewe" <PeterHuewe@gmx.de> wrote:
>>>
>>> Hi,
>>>
>>> I would like to 'invite' all interested parties in a short TPM minisummit
>>> where we can discuss the following hot topics of the TPM subsystem over a
>>> beer or two:
>>> - State of the TPM Subsystem
>>> - De-/Initialization Mess
>>> - Devm'ification
>>> - Testing
>>> - TPM 2.0 Support
>>> - Dependencies / interaction with other subsystems (e.g. keyring / IMA)
>>> - Status of old 1.1b TPM drivers, deprecation plans
>>> - ...
>>>
>> I am unlikely to be there, but I have a feature request / food for
>> thought:
>>
>> Using a mandatory userspace daemon (e.g. trousers) for TPM access
>> sucks. Might it be possible to teach the kernel to handle context
>> save and restore and let multiple processes open the device at once?
>> Then a daemon wouldn't be necessary.
>
>
> Why add the complexity of swapping of authenticated sessions and keys into
> the kernel if you can handle this in userspace? You need a library that is
> aware of the number of key slots and slots for sessions in the TPM and swaps
> them in at out when applications need them. Trousers is such a library that
> was designed to cope with the limitations of the device and make its
> functionality available to all applications that want to access it.
>
Trousers is a daemon, not a library, and it's really quite scary.
Admittedly, my information may be a bit out of date, but trousers
contains way too much code (it has layers in the server!), it has
parsers and serializers of questionable safety (I found one critical
bug *by accident* a couple years ago), it listens on a TCP socket
(this should really be a UNIX socket under /run), it's heavy-weight,
and it does far more than necessary (all it needs to do is context
switching).
Also, Trousers is quite unfriendly to non-Trousers-using programs
(e.g. chapsd/trunks).
If the kernel helped with context switching, then user programs that
actually want Trousers' functionality could run their own copies.
--Andy
next prev parent reply other threads:[~2014-10-07 17:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 9:01 [Ksummit-discuss] " Peter Huewe
2014-09-23 16:42 ` Andy Lutomirski
2014-10-07 17:54 ` [Ksummit-discuss] [TrouSerS-tech] " Stefan Berger
2014-10-07 17:58 ` Andy Lutomirski [this message]
2014-10-07 18:02 ` [Ksummit-discuss] [tpmdd-devel] " Jason Gunthorpe
2014-10-07 18:47 ` Stefan Berger
2014-10-07 18:59 ` Andy Lutomirski
2014-10-13 0:03 ` Mimi Zohar
2014-10-08 20:59 ` Josh Triplett
2014-10-07 19:22 ` [Ksummit-discuss] " Jarkko Sakkinen
2014-10-12 23:45 ` [Ksummit-discuss] [tpmdd-devel] " Mimi Zohar
2014-10-12 18:17 ` [Ksummit-discuss] [tpmdd-devel] " Jarkko Sakkinen
2014-10-12 21:16 ` Peter Huewe
2014-10-13 5:17 ` Peter Huewe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrWoAkYTjetqm1e9zYGvetEhn0WQL5poLWv_saQktcHu7g@mail.gmail.com \
--to=luto@amacapital.net \
--cc=james.l.morris@oracle.com \
--cc=jarkko.sakkinnen@linux.intel.com \
--cc=keyrings@linux-nfs.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=stefanb@linux.vnet.ibm.com \
--cc=tpmdd-devel@lists.sourceforge.net \
--cc=trousers-tech@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox