Messages in this thread | | | Date | Thu, 9 Feb 2017 03:06:38 -0600 | From | "Dr. Greg Wettstein" <> | Subject | Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion |
| |
On Jan 30, 11:58pm, Jarkko Sakkinen wrote: } Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
Good morning, I hope the day is going well for everyone.
> I'm kind dilating to an opinion that we would leave this commit out > from the first kernel release that will contain the resource manager > with similar rationale as Jason gave me for whitelisting: get the > basic stuff in and once it is used with some workloads whitelisting > and exhaustion will take eventually the right form. > > How would you feel about this?
I wasn't able to locate the exact context to include but we noted with interest Ken's comments about his need to support a model where a client needs a TPM session for transaction purposes which can last a highly variable amount of time. That and concerns about command white-listing, hardware denial of service and related issues tend to underscore our concerns about how much TPM resource management should go into the kernel.
Once an API is in the kernel we live with it forever. Particularly with respect to TPM2, our field experiences suggest it is way too early to bake long term functionality into the kernel.
Referring back to Ken's comments about having 20+ clients waiting to get access to the hardware. Even with the focus in TPM2 on having it be more of a cryptographic accelerator are we convinced that the hardware is ever going to be fast enough for a model of having it directly service large numbers of transactions in something like a 'cloud' model?
The industry has very solid userspace implementations of TPM2. It seems that with respect to resource management about all we would want in the kernel is enough management to allow multiple privileged userspace process to establish a root of trust for a TPM2 based userspace instance with subsequent relinquishment of privilege. At that point one has the freedom to implement all sorts of policy.
Given the potential lifespan of these security technologies I think a kernel design needs to factor in the availability of trusted execution environment's such as SGX as well. Politics aside, such environments do have the ability to significantly modify the guarantees which can be afforded to architectural models which focus on using the hardware TPM as a root of trust for userspace implementations of 'TPM' functionality and policy.
We can always add functionality to the kernel but we can never subtract. It is way too early to lock security architecture decisions into the kernel.
> /Jarkko
Have a good weekend.
Greg
}-- End of excerpt from Jarkko Sakkinen
As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "If I'd listened to customers, I'd have given them a faster horse." -- Henry Ford
| |