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 own
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 confused.
May it be
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()) expects
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 it in
in
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). The parent
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
map resulting
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
things that
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 available
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/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 it
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 common.
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
While it does this, there's no need for it to have a RM interface
because what it does between the acquisition
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 TPM
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 both
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
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
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 6/28/2017 1:28 PM, Jarkko Sakkinen wrote:
> On Mon, Jun 26, 2017 at 08:33:59AM -0400, Mimi Zohar wrote:
>> On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
>>> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:
>>
>>
>>> To move this forward and be more constructive here's
On 8/8/2017 3:11 PM, Jarkko Sakkinen wrote:
> On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
>> Are you sure this is a good idea?
>> On lpc systems this more or less stalls the bus, including
keyboard/mouse (if connected via superio lpc).
>>
>> On which systems have you tested
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 7/25/2017 11:44 AM, Roberto Sassu wrote:
Don't report measurements if the file digest has been included in
an uploaded digest list.
The advantage of this solution is that the boot time overhead, when
a TPM is available, is very small because a PCR is extended only
for unknown files. The
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/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 5/17/2017 3:25 AM, Roberto Sassu wrote:
The format of digestN is: :\0, the same used
for the file digest.
Since the format is changing from the SHA-1 log format anyway ...
How do people feel about the colon and null terminated string format for
algorithm identifiers?
The TCG standard
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", does
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
On 5/18/2017 5:38 AM, Roberto Sassu wrote:
There cannot be buffer overflow, because the length of each digest
field is known.
Crypto Agile: pcr[4] total_digest_len[4]
digest1_len[4] digest1[digest1_len] ...
The way I read this, the digest length is supplied by the caller,
On 5/18/2017 5:38 AM, Roberto Sassu wrote:
On 5/17/2017 6:28 PM, Ken Goldman wrote:
On 5/17/2017 3:25 AM, Roberto Sassu wrote:
The format of digestN is: :\0, the same used
for the file digest.
Since the format is changing from the SHA-1 log format anyway ...
How do people feel about
On 5/16/2017 8:53 AM, Roberto Sassu wrote:
A new IMA measurement list format, called Crypto Agile, will be introduced
shortly to take full advantage of the algorithm flexibility of TPM 2.0.
With the new format, it will be possible to provide for each list entry
multiple digests, each calculated
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
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 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/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/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
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 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
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 8/8/2017 3:11 PM, Jarkko Sakkinen wrote:
> On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
>> Are you sure this is a good idea?
>> On lpc systems this more or less stalls the bus, including
keyboard/mouse (if connected via superio lpc).
>>
>> On which systems have you tested
On 7/25/2017 11:44 AM, Roberto Sassu wrote:
Don't report measurements if the file digest has been included in
an uploaded digest list.
The advantage of this solution is that the boot time overhead, when
a TPM is available, is very small because a PCR is extended only
for unknown files. The
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 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
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 6/28/2017 1:28 PM, Jarkko Sakkinen wrote:
> On Mon, Jun 26, 2017 at 08:33:59AM -0400, Mimi Zohar wrote:
>> On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
>>> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:
>>
>>
>>> To move this forward and be more constructive here's
On 12/12/2020 9:22 PM, Mimi Zohar wrote:
Ok. Going forward, it sounds like we need to define a new
"boot_aggregate" record. One that contains a version number and PCR
mask.
Just BTW, there is a TCG standard for a TPM 2.0 PCR mask that works
well.
There is also a standard for an event log
On 5/20/2019 7:15 PM, Lakshmi wrote:
On 5/17/19 7:41 AM, Ken Goldman wrote:
Hi Ken,
Apologize for the delay in responding.
Since a platform typically uses only a few signing keys, 4 bytes makes
the chance of a collision quite small. The collision would have to be
within the same log
On 5/14/2019 1:14 PM, Lakshmi wrote:
The motive behind this patch series is to measure the public key
of the IMA signature signer in the IMA log.
I have some questions about the rationale for the design ...
> The IMA signature of the file, logged using ima-sig template, contains
the key
On 5/16/2019 9:29 PM, Lakshmi wrote:
On 5/16/19 7:34 AM, Ken Goldman wrote:
But outside the client machine this key id is not sufficient to
uniquely determine which key the signature corresponds to.
Why is this not sufficient?
In my implementation, I create a lookup table at the attestation
On 12/29/2018 10:33 PM, Mimi Zohar wrote:
But the problem you've described is on a cold boot, not a soft reboot.
Both the soft reboot and kexec are working properly. It seems the
difference is that on a cold boot, the TPM takes longer to initialize.
I would expect this.
The TPM doesn't
On 12/30/2018 8:22 AM, Michael Niewöhner wrote:
difference is that on a cold boot, the TPM takes longer to initialize.
Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does
not solve the problem. So the problem is NOT that the TPM takes longer to
initialize. Even
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). The parent
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
map resulting
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 common.
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
While it does this, there's no need for it to have a RM interface
because what it does between the acquisition
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 TPM
On 5/16/2017 8:53 AM, Roberto Sassu wrote:
A new IMA measurement list format, called Crypto Agile, will be introduced
shortly to take full advantage of the algorithm flexibility of TPM 2.0.
With the new format, it will be possible to provide for each list entry
multiple digests, each calculated
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", does
On 5/17/2017 3:25 AM, Roberto Sassu wrote:
The format of digestN is: :\0, the same used
for the file digest.
Since the format is changing from the SHA-1 log format anyway ...
How do people feel about the colon and null terminated string format for
algorithm identifiers?
The TCG standard
On 5/18/2017 5:38 AM, Roberto Sassu wrote:
On 5/17/2017 6:28 PM, Ken Goldman wrote:
On 5/17/2017 3:25 AM, Roberto Sassu wrote:
The format of digestN is: :\0, the same used
for the file digest.
Since the format is changing from the SHA-1 log format anyway ...
How do people feel about
On 5/18/2017 5:38 AM, Roberto Sassu wrote:
There cannot be buffer overflow, because the length of each digest
field is known.
Crypto Agile: pcr[4] total_digest_len[4]
digest1_len[4] digest1[digest1_len] ...
The way I read this, the digest length is supplied by the caller,
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
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 available
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/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 it
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
things that
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 both
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 it in
in
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()) expects
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 own
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 confused.
May it be
70 matches
Mail list logo
