On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
> On Sep 22, 2014 2:07 AM, "Peter Huewe" <[email protected]> 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.
Stefan
>
> There would still be a need for some policy (e.g. who can clear the
> SRK), but that should be manageable. Maybe there should be two device
> nodes. /dev/tpm_unpriv would be fully virtualized for access by
> multiple processes, but it would only allow use of the key hierarchy
> and read access to PCRs. /dev/tpm_priv would allow NV access, PCR
> writes, SRK clears, etc.
>
> --Andy
>
>> Please register your interest by filling out this doodle
>> http://doodle.com/q9ezcrivhqrktw6u
>>
>> I'm not sure if I can get any funding for the summit... but maybe I can arrange something.
>>
>>
>> Also I'm trying to bring along some TPM samples from my employer if possible.
>>
>>
>> Thanks
>> Peter
>>
>> p.s.: experienced kernel developers welcome :)
>> _______________________________________________
>> Ksummit-discuss mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> TrouSerS-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/trousers-tech
>
On Tue, Oct 7, 2014 at 10:54 AM, Stefan Berger
<[email protected]> wrote:
> On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
>>
>> On Sep 22, 2014 2:07 AM, "Peter Huewe" <[email protected]> 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
On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
> 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.
How does trousers work with the kernel when the kernel is also using
TPM key slots for IMA/keyring/whatever?
Jason
On 10/07/2014 02:02 PM, Jason Gunthorpe wrote:
> On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
>
>> 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.
> How does trousers work with the kernel when the kernel is also using
> TPM key slots for IMA/keyring/whatever?
IIRC it only uses a single key slot and swaps all keys in and out of
that one. If the kernel was to fill up all key (and sessions) slots, TSS
would probably not work anymore.
Another argument for the TSS is that you also wouldn't want applications
to swap out each others keys and sessions and leave them out or assume
that they would always cleanup if they do not currently need them.
Regards,
Stefan
On Tue, Oct 7, 2014 at 11:47 AM, Stefan Berger
<[email protected]> wrote:
> On 10/07/2014 02:02 PM, Jason Gunthorpe wrote:
>>
>> On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
>>
>>> 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.
>>
>> How does trousers work with the kernel when the kernel is also using
>> TPM key slots for IMA/keyring/whatever?
>
>
> IIRC it only uses a single key slot and swaps all keys in and out of that
> one. If the kernel was to fill up all key (and sessions) slots, TSS would
> probably not work anymore.
>
> Another argument for the TSS is that you also wouldn't want applications to
> swap out each others keys and sessions and leave them out or assume that
> they would always cleanup if they do not currently need them.
That argument seems backwards. If you're worried about applications
(or trousers itself!) failing to clean up, then shouldn't the kernel
driver clean up orphaned key slots itself?
Also, what protects the kernel from having slot 0 get stomped on or,
worse, inappropriately used by a misbehaving or malicious user
program? Is the authorization session mechanism really secure against
intentional abuse by users of the same machine?
--Andy
On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
> On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
> >On Sep 22, 2014 2:07 AM, "Peter Huewe" <[email protected]> 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.
One justification might be that kernel is also using TPM? TrouSerS can
not manage session for kernel internal use.
> Stefan
/Jarkko
On Tue, Oct 07, 2014 at 02:47:06PM -0400, Stefan Berger wrote:
> On 10/07/2014 02:02 PM, Jason Gunthorpe wrote:
> >On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
> >
> >>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.
> >How does trousers work with the kernel when the kernel is also using
> >TPM key slots for IMA/keyring/whatever?
>
> IIRC it only uses a single key slot and swaps all keys in and out of that
> one. If the kernel was to fill up all key (and sessions) slots, TSS would
> probably not work anymore.
>
> Another argument for the TSS is that you also wouldn't want applications to
> swap out each others keys and sessions and leave them out or assume that
> they would always cleanup if they do not currently need them.
At a minimum, the kernel needs to reserve some number of keys and
sessions for itself (and we should *not* assume that number must be 1).
That means we need some level of kernel arbitration to expose the
remaining items to userspace. Given that existing level of arbitration,
we don't necessarily *have* to add support for swapping resources in and
out between applications, but we *could* support giving individual TPM
resources to individual userspace processes on an exclusive basis, and
give an error if we run out.
Whether we add dynamic resource management beyond that to userspace or
the kernel is a good question.
- Josh Triplett
On Tue, 2014-10-07 at 22:22 +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
> > On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
> > >On Sep 22, 2014 2:07 AM, "Peter Huewe" <[email protected]> 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.
>
> One justification might be that kernel is also using TPM? TrouSerS can
> not manage session for kernel internal use.
I had a discussion way back when with Rajiv Andrade, when he was the
maintainer. Instead of assuming Trousers didn't use up all the slots,
one slot would be reserved for the kernel's use. Need to check and see
if this was ever implemented.
Mimi
On Tue, 2014-10-07 at 11:59 -0700, Andy Lutomirski wrote:
> On Tue, Oct 7, 2014 at 11:47 AM, Stefan Berger
> <[email protected]> wrote:
> > On 10/07/2014 02:02 PM, Jason Gunthorpe wrote:
> >>
> >> On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
> >>
> >>> 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.
> >>
> >> How does trousers work with the kernel when the kernel is also using
> >> TPM key slots for IMA/keyring/whatever?
> >
> >
> > IIRC it only uses a single key slot and swaps all keys in and out of that
> > one. If the kernel was to fill up all key (and sessions) slots, TSS would
> > probably not work anymore.
> >
> > Another argument for the TSS is that you also wouldn't want applications to
> > swap out each others keys and sessions and leave them out or assume that
> > they would always cleanup if they do not currently need them.
>
> That argument seems backwards. If you're worried about applications
> (or trousers itself!) failing to clean up, then shouldn't the kernel
> driver clean up orphaned key slots itself?
As I understand it, this isn't an issue of "cleaning up", but of
mediating the limited resources, by "swapping" keys in and out as
needed.
Mimi
> Also, what protects the kernel from having slot 0 get stomped on or,
> worse, inappropriately used by a misbehaving or malicious user
> program? Is the authorization session mechanism really secure against
> intentional abuse by users of the same machine?
>
> --Andy