I also see email coming from linux-security-mod...@vger.kernel.org.
Should I also subscribe to that one? Is there another one for the TPM
device driver? IMA?
On 9/15/2017 1:18 PM, Jarkko Sakkinen wrote:
Hi
Many people were kicked out from the SourceForge mailing list in the
July because
Newbie question: Do I have to subscribe, or are email addresses being
migrated?
On 9/15/2017 1:18 PM, Jarkko Sakkinen wrote:
Hi
Many people were kicked out from the SourceForge mailing list in the
July because SF required a resubscription, including non-human users,
such as patchwork.
We
On 9/6/2017 12:12 PM, Jason Gunthorpe wrote:
The problem with this approach is that the TPM could totally block
the CPU for very long periods of time.
It seems very risky to enable..
How would you characterize "very long"?
The TPM vendors confirm that they empty the FIFO at internal speeds
On 8/15/2017 4:13 PM, Haris Okanovic wrote:
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an
On 8/14/2017 6:10 AM, Jarkko Sakkinen wrote:
Nuvoton, ST Micro, and Infineon confirmed that the TPM empties a byte from
the FIFO in under 1 usec. So, even with a static burst count, the entire
FIFO would empty in under 10 usec.
Does this break anything lets say in a decade time frame? If it
On 8/13/2017 7:53 PM, msuchanek wrote:
About 500 out of 700 mainboards sold today has a PS/2 port which is
probably due to prevalence of legacy devices and usbhid limitations.
Similarily many boards have serial and parallel hardware ports.
In all diagrams detailed enough to show these ports I
On 8/9/2017 4:43 PM, Peter Huewe wrote:
Yes that's bad, especially with current msleep(5) is actually
msleep(20). However, please also keep in mind SPI tpms show a much
higher burst count value, (255) our I2C TPM SLB9645 even shows
something in the range of 1k. :)
One of our platforms has a
Following up on this thread based on this week's TCG call ...
1 - burstCount can safely be ignored on writes. This is explicit in
most places in the TCG spec. In places where it is not explicit, it was
simply an editorial omission. We are going through the spec and adding
"without incurring
On 8/9/2017 5:00 PM, Peter Huewe wrote:
Since we are the linux kernel, we do have to care for legacy
devices. And a system with LPC, PS2Mouse on SuperIO and a TPM are not
that uncommon.
And heck, we even have support for 1.1b TPM devices
Understood. However, remember that SuperIO is a
On 8/8/2017 3:11 PM, Jarkko Sakkinen wrote:
On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
Imho: NACK from my side.
After these viewpoints definitive NACK from my side too...
I responded to the thread comments separately. However, assuming NACK
is the final response, I have
On 6/20/2017 3:31 PM, Jason Gunthorpe wrote:
+#define TPM_ORD_STARTUP 153 +#define TPM_ST_CLEAR 1
We should really have a tpm1.h and tpm2.h that has all these various
constants and things instead of open coding them randomly all over..
While you're doing that, perhaps put the ordinal
At least a question, maybe a bug ...
What is the expected behavior for the resource manager when it receives
contextsave for a transient object?
]
~~
Use case:
Creating an RSA primary key can take a long time. I've seen it take 90
seconds. The SRK will probably be made persistent.
On 5/10/2017 7:54 PM, Stefan Berger wrote:
> Implement the request_locality function. To set the locality on the
> backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send
> a command to the backend to set the locality for the next commands.
When this says "for the next commands",
On 4/23/2017 9:32 PM, Peter Huewe wrote:
> 38=0x26= invalid post init, which means tpm did not receive tpm_startup
> command after reset.
A minor observation:
While the TPM 1.2 specification listed error codes in decimal, TPM 2.0
uses hex, and further has a lot of bit level encoding.
Thus, for
On 4/24/2017 10:50 AM, Paul Menzel wrote:
>
> Thank you for the quick reply. As this is during resume, could you
> please point me to documentation, what is expected for resume from the
> firmware?
If "resume" means: from the sleep state where the platform suspends to
RAM and there is no OS
, getcapability,
reading NV indexes, policy sessions. I did the RSA and ECC variants in
parallel, so there should have been a bit of swapping.
On 3/29/2017 2:40 PM, James Bottomley wrote:
> On Tue, 2017-03-28 at 17:39 -0400, Ken Goldman wrote:
>> I have a persistent object at
I have a persistent object at 8101.
getcapability through /dev/tpm0 shows it. The same command through
/dev/tpmrm0 does not. This causes further problems in the application.
While transient objects are per connection, IMHO persistent objects
should be global.
~~
Warning: I think I'm
On 3/20/2017 5:54 AM, alexander.stef...@infineon.com wrote:
>
> There are a few special cases that need some thought though. For
> example, it is possible to use an upgrade to switch the TPM family
> from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> the kernel reinitialize the
On 3/13/2017 3:10 AM, Peter Huewe wrote:
> And yes you are right there is currently no way, except for trial and
> error, for the userspace to determine this. So an interface to get
> this information makes sense to me.
In practice, I suspect that a single user space application won't
support
On 3/8/2017 4:58 AM, Roberto Sassu wrote:
>
> Regarding modifying the digest before it is passed to the extend
> function, can truncating/padding with zeros be considered
> a standard? If not, verifiers have to look at the software
> implementation, in order to find how the digest was modified.
>
On 2/26/2017 1:30 PM, Dr. Greg Wettstein wrote:
>
> For example, Ken's tools which come in his TSS2 library, don't work
> properly with the 'spaces' device due to the virtualization lifetime.
> As an example, the getcapability call will 'lie' about the number of
> transient handles which are
On 2/22/2017 12:39 PM, James Bottomley wrote:
>
> Right at the moment the kernel use of tpm2 looks like
>
> acquire chip->tpm_mutex
> load key
> process key
> unload key
> release chip->tpm_mutex
The advantage to context save/ context load over load / flush
is that load requires the parent(s).
On 2/21/2017 1:24 PM, Nayna wrote:
>
> [snip]
>>
>> 1. Take locks.
>> 2. Load transient objects from the backing storage by using ContextLoad
>> and map virtual handles to physical handles.
>> 3. Perform the transaction.
>> 4. Save transient objects to backing storage by using ContextSave and
On 2/10/2017 11:46 AM, James Bottomley wrote:
> On Fri, 2017-02-10 at 04:03 -0600, Dr. Greg Wettstein wrote:
>> On Feb 9, 11:24am, James Bottomley wrote:
>> quote: 810 milliseconds
>> verify signature: 635 milliseconds
> ...
>
> Part of the way of reducing the latency is not to use the TPM for
>
On 1/31/2017 5:55 PM, James Bottomley wrote:
>
> I can do that, but I think this should be higher than debug. If this
> trips, something an application was doing will fail with a non TPM
> error and someone may wish to investigate why. Having a kernel message
> would help with that (but they
Should tabrm5 have the session swapping yet? Is there a different head
I should be using?
I have the following test:
create a primary storage key
create 2 signing keys under the storage key, each with a different
password
load all 2 keys
create an hmac session
sign
On 1/30/2017 11:04 AM, James Bottomley wrote:
>
> This depends what your threat model is. For ssh keys, you worry
> that someone might be watching, so you use HMAC authority even for a
> local TPM.
If someone can "watch" my local process, they can capture my password
anyway. Does using a
> You do not need to send a new patch set version as long as this
> one gets peer tested. And it needs to be tested without hacks
> like plumbing TCPA with TPM 2.0 in QEMU. OF code paths needs to
> be peer tested to be more specific.
>
> For me the code itself looks good but I simply cannot take
On 1/27/2017 5:04 PM, James Bottomley wrote:
>> Beware the nasty corner case:
>>
>> - Application asks for a session and gets 0200
>>
>> - Time elapses and 0200 gets forcibly flushed
>>
>> - Later, app comes back, asks for a second session and again gets
>> 0200.
>>
>> - App gets very
On 1/27/2017 7:32 PM, James Bottomley wrote:
>
> Sessions are also isolated during each instance of a tpm space. This
> means that spaces shouldn't be able to see each other's sessions and
> is enforced by ensuring that a space user may only refer to sessions
> handles that are present in their
On 1/29/2017 10:25 AM, Jarkko Sakkinen wrote:
>
> We should probably block the following from /dev/tpms0 by default:
>
> 1. ContextLoad for sessions.
> 2. ContextSave for sessions.
> 3. Vendor specific commands.
This is reasonable to me. The only vendor specific commands I currently
know of are
On 1/25/2017 8:04 PM, James Bottomley wrote:
> This leads to a problem: we have to have access to the session context
> to pull this trick, and that means we have to disallow TPM users from
> calling ContextSave on a session otherwise they could DoS us by
> inducing an unremediable
On 1/18/2017 3:48 PM, James Bottomley wrote:
> In a TPM2, sessions can be globally exhausted once there are
> TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved).
> The Strategy for handling this is to keep a global count of all the
> sessions along with their creation time.
On 1/19/2017 7:41 AM, Jarkko Sakkinen wrote:
>
> I actually think that the very best solution would be such that
> sessions would be *always* lease based. So when you create a
> session you would always loose within a time limit.
>
> There would not be any special victim selection mechanism. You
>
> The current TPM 2.0 device driver extends only the SHA1 PCR bank
> but the TCG Specification[1] recommends extending all active PCR
> banks, to prevent malicious users from setting unused PCR banks with
> fake measurements and quoting them.
>
> The existing in-kernel interface(tpm_pcr_extend())
On 1/20/2017 8:23 AM, Jarkko Sakkinen wrote:
>
> I'm talking about not trying to detect if something gets deleted. When
> something gets created you would go through the global list of sessions
> and check if it is used. If so, it must be that the session was deleted
> at some point.
Are you
On 1/16/2017 6:18 PM, James Bottomley wrote:
>
> Basically this means that the advice to virtualize session handles
> in the TCG RM document is wrong and we have to use physical handles.
> I'll redo the implementation for this ... and now, since we'll have
> nothing to use as an index, it probably
The result of getcapability for transient objects should normally be
virtual handles that the application sees, not the TPM handles.
However, there is a corner case - auditing the getcapability command.
Audit is a TPM function that maintains a hash of commands
and responses, and
Question 1 of 2:
The RM is virtualizing transient handles. When getcapability returns
TPM handles, they have to be mapped to the virtual handles.
Where should the mapping occur? RM vs. user space TSS?
- The RM sees the TPM physical handles, and knows the mapping to virtual
handles for that
I think I may know why this is failing.
in tpm2_auto_startup(), the device driver gets the command handle count
from the TPM using a getcapability TPM2_CAP_COMMANDS.
The TPM does not treat the TPM2_FlushContext as a handle, because it can
flush a session that is not TPM resident. Thus,
On 1/10/2017 5:42 PM, Jason Gunthorpe wrote:
> On Tue, Jan 10, 2017 at 05:31:45PM -0500, Ken Goldman wrote:
>> On 1/10/2017 3:08 PM, Jason Gunthorpe wrote:
>>>> 4 - Is a write() error desirable? I think the application would prefer
>>>> a TPM formatted response
On 1/11/2017 5:00 AM, Andreas Fuchs wrote:
>
> You need to do virtualization inside bodies, because TPM2_FlushContext
> carries it's handles inside the parameter body.
> Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)
It's not huge, not even a blunder. The TPM spec Part 3 has
On 1/10/2017 3:08 PM, Jason Gunthorpe wrote:
>> 4 - Is a write() error desirable? I think the application would prefer
>> a TPM formatted response like TPM_RC_VALUE.
>
>
> IMHO, I prefer the write errno, but we need to clearly define what our
> errnos means. Errnos used by RM should not overlap
1 - Is this the correct place to post potential RM issues?
2 - Here's my test case:
test0: primary key 80ff
test0: signing key 0 80fe
test0: signing key 1 80fd
test0: session 0200
test0: sign with 0200 80fe
test0: sign with 0200 80fd
listTransientObjects:
On 1/3/2017 6:22 PM, James Bottomley wrote:
>
> Note that google took an alternative approach and modified their TSS to
> work with a MD5-SHA1 signature:
>
> https://chromium-review.googlesource.com/#/c/420811/
>
> But this requires a modification to the TPM as well, which we can't do.
Right.
On 1/9/2017 6:16 PM, Jarkko Sakkinen wrote:
>
> Here's my cuts for the kernel:
>
> - Kernel virtualizes handle areas. It's mechanical.
> - Kernel does not virtualize bodies. It's not mechanical.
> - At least the first version of the RM will not do other than session
> isolation for sessions.
Is
On 1/9/2017 12:04 PM, James Bottomley wrote:
> I didn't really see a need to use an emulated TPM in the kernel until
> Jarkko's smoke tests caused a DA lockout on my physical TPM at which
> point not impacting all my other TPM based stuff while playing with
> the kernel suddenly seemed important.
On 1/5/2017 2:20 PM, Jason Gunthorpe wrote:
>
> I'd rather give up features (eg policy sessions, if necessary) for the
> unpriv fd than give up security of the unpriv fd.
Please don't give up policy. Nearly every use case of that we think of
for TPM 2.0 uses policy sessions.
E.g.,
In 1.2, PCR
On 1/6/2017 3:43 AM, Andreas Fuchs wrote:
> Am 05.01.2017 um 19:06 schrieb James Bottomley:
>
> Then how about blocking
> TPM2_GetCapabilities(TPM_CAP_HANDLES, 0x8000) ?
Even just for debugging, this is a really useful command.
Won't the RM have a mapping from TPM to RM handle for
transient
On 1/3/2017 7:17 PM, Jason Gunthorpe wrote:
>
> Well, by policy you mean 'know the owner password' which at least I am
> *very* nervous about exposing beyond the super user - certainly in my
> embedded systems.
For TPM 2.0, the "owner" is mostly just the controller of the storage
hierarchy. It's
On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
>
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular peice of hardware and it is equally able to
> support a RM.
I suspect that TPM 2.0 is different enough from 1.2 that there may be
little common code.
My
On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
>
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular piece of hardware and it is equally able to
> support a RM.
I suspect that TPM 2.0 and TPM 1.2 are so different that there may be
little or no code in
On 1/3/2017 11:36 AM, James Bottomley wrote:
> To be honest I can't see much use for getting the transient handles
> and all the other handles you'd be interested in aren't virtualized.
Probably the biggest use case for enumerating handles is NV indexes,
where one is looking for EK certificates
It appears that an open() to the TPM doesn't block if another process
has /dev/tpm0 open. It returns -1, an error.
Questions:
Is this expected behavior?
Was this also true for 1.2?
Is there any way to change it. I didn't set O_NOBLOCK. Is there
perhaps an ioctl()?
Is this something that
I hope this isn't a breach of etiquette, but I was asked to announce
that the TSS for TPM 2.0 now has a git repository as well as tarballs.
https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/
The core TSS library code has been stable for the past 15 months, except
for reorganization and
On 7/29/2016 1:14 PM, Jason Gunthorpe wrote:
>
> The bios log is defined to be host endian?
>
> Please reference the standard in a comment that these structs are
> coming from.
The BIOS log is little endian. That is, all multi-byte values are
little endian. Examples are the pcrIndex,
On 7/25/2016 12:47 PM, Peter.Huewe-
> Speaking of PCClient based platforms, everything with:
> - Kernel >4.0 works with CRB out of the box, with FIFO if tpm_tis.force=1 as
> module parameter
> - Kernel >4.4 works with FIFO out of the box
1 - How does a user know whether the TPM will use CRB or
For distros or kernels that do not include a TPM 2.0 device driver:
1 - Is it possible to build and install a driver without rebuilding the
kernel?
2 - If so, are there definitive instructions on how to do it?
I've heard snippets that say a kernel that has a built-in TPM 1.2 driver
cannot
Is there a web site or other document that lists which distros or
kernels include a TPM 2.0 driver?
I support a TPM 2.0 user space TSS. Not seeing /dev/tpm0 is a typical
error that prospective users see, and I'd like to give them some guidance.
If there is no such page, and people are willing
On 1/13/2016 8:39 AM, David Howells wrote:
> Hi Peter, Jarkko,
>
> Is the TPM emulator likely to go upstream at any point? Or is it waiting for
> some sort of update?
I'm not Peter or Jarkko, but I maintain the TPM emulator for both TPM
1.2 and TPM 2.0.
TPM 1.2 is very stable. The changes in
60 matches
Mail list logo
