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  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]
Date:	Tue, 07 Oct 2014 13:54:41 -0400
From:	Stefan Berger <>
To:	Andy Lutomirski <>,
	Peter Huewe <>
	"" <>,
	LSM List <>,,
	James Morris <>,,
Subject: Re: [TrouSerS-tech] [Ksummit-discuss] TPM MiniSummit @ LinuxCon Europe

On 09/23/2014 12:42 PM, Andy Lutomirski wrote:
> On Sep 22, 2014 2:07 AM, "Peter Huewe" <> 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.


> 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
>> 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
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> TrouSerS-tech mailing list

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists