[Ksummit-discuss] TPM MiniSummit @ LinuxCon Europe

[Ksummit-discuss] TPM MiniSummit @ LinuxCon Europe

[Peter Huewe]

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
 - ...


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 :)

Re: [Ksummit-discuss] TPM MiniSummit @ LinuxCon Europe

[Andy Lutomirski]

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.

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
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Stefan Berger]

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.

    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
>> Ksummit-discuss@lists.linuxfoundation.org
>> 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
> TrouSerS-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/trousers-tech
>

Re: [Ksummit-discuss] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Andy Lutomirski]

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

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Jason Gunthorpe]

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

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Stefan Berger]

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

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Andy Lutomirski]

On Tue, Oct 7, 2014 at 11:47 AM, Stefan Berger
<stefanb@linux.vnet.ibm.com> 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

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Mimi Zohar]

On Tue, 2014-10-07 at 11:59 -0700, Andy Lutomirski wrote: 
> On Tue, Oct 7, 2014 at 11:47 AM, Stefan Berger
> <stefanb@linux.vnet.ibm.com> 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

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Josh Triplett]

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

Re: [Ksummit-discuss] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Jarkko Sakkinen]

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" <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.

One justification might be that kernel is also using TPM? TrouSerS can
not manage session for kernel internal use.

>    Stefan

/Jarkko

Re: [Ksummit-discuss] [tpmdd-devel] [TrouSerS-tech] TPM MiniSummit @ LinuxCon Europe

[Mimi Zohar]

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" <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.
> 
> 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

Re: [Ksummit-discuss] [tpmdd-devel] TPM MiniSummit @ LinuxCon Europe

[Jarkko Sakkinen]

Hey,

apologies for top-posting but which day/time/place is this going to be held?

/Jarkko

On Tue, Sep 23, 2014 at 09:42:33AM -0700, 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.
> 
> 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
> > Ksummit-discuss@lists.linuxfoundation.org
> > 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
> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [Ksummit-discuss] [tpmdd-devel] TPM MiniSummit @ LinuxCon Europe

[Peter Huewe]

Hi 
> apologies for top-posting but which day/time/place is this going to be held?
I'd suggest that we either meet tomorrow (Monday) during the other BoF Sessions @ 5:30pm or afterwards.
Does one of the attendees have a conflict with the BOFs or the VIP Reception?
Personally, I think it's most important that you Jarkko can join the meetup since you're developing the most on TPM2.0.


Since I don't have a special room booked, I'd suggest that we meet in the "Lobby" and then head out for a beer - since I haven't prepared any slides I would organize the meeting as a BOF.

Thanks,
Peter

Re: [Ksummit-discuss] [tpmdd-devel] TPM MiniSummit @ LinuxCon Europe

[Peter Huewe]

Hi,
we got an official slot at Monday 5.30pm in Room 01 (http://sched.co/1D5VKBL) :)

Peter


Gesendet: Sonntag, 12. Oktober 2014 um 23:16 Uhr
Von: "Peter Huewe" <PeterHuewe@gmx.de>
An: "Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.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,, linux-ima-devel@lists.sourceforge.net, trousers-tech@lists.sourceforge.net
Betreff: Re: [tpmdd-devel] [Ksummit-discuss] TPM MiniSummit @ LinuxCon Europe
Hi
> apologies for top-posting but which day/time/place is this going to be held?
I'd suggest that we either meet tomorrow (Monday) during the other BoF Sessions @ 5:30pm or afterwards.
Does one of the attendees have a conflict with the BOFs or the VIP Reception?
Personally, I think it's most important that you Jarkko can join the meetup since you're developing the most on TPM2.0.


Since I don't have a special room booked, I'd suggest that we meet in the "Lobby" and then head out for a beer - since I haven't prepared any slides I would organize the meeting as a BOF.

Thanks,
Peter

------------------------------------------------------------------------------
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://p.sf.net/sfu/Zoho
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel[https://lists.sourceforge.net/lists/listinfo/tpmdd-devel]