Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
On Thu, Feb 09, 2017 at 11:29:51AM -0800, James Bottomley wrote: > On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote: > > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > > The current patch set does not define policy. The simple policy > > > addition that could be added soon is the limit of connections > > > because it is easy to implement in non-intrusive way. > > > > It is also trivial for a userspace RM to limit the number of sessions > > or connections or otherwise to manage this limitation. It is hard to > > see why we'd need kernel support for this. > > Because the kernel is a primary TPM user. When I said 'this' I meant a kernel policy to limit the number of user connections. Jason -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote: > 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. This actually is far too strong a statement: Once you make API guarantees, you have to live with them forever, but there's a considerable difference between an API guarantee and the API itself. For instance the kernel overlay filesystem has gone through several iterations of file whiteouts (showing a file as deleted above a read only copy): we began with an inode flag, moved to an extended attribute and finally ended up with a device. Each of those three changes was fairly radical to the VFS API, but didn't fundamentally alter the API guarantee (that users wouldn't see a file after it was deleted on an overlay). The API guarantee /dev/tpms0 is adding is that you won't see TPM out of memory errors based on what other people are doing, so I think it's a simple isolation guarantee we can live with long term. I think that's a solidly defensible one. However, right at the moment the guarantee isn't that you won't be affcted by *anything* another user does, so it's a weak guarantee: you will see uncorrectable regapping errors based on what others are doing and you will see global session exhaustion. I think we begin with the defensible weak guarantee and discuss how to strengthen it. James -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote: > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > The current patch set does not define policy. The simple policy > > addition that could be added soon is the limit of connections > > because it is easy to implement in non-intrusive way. > > It is also trivial for a userspace RM to limit the number of sessions > or connections or otherwise to manage this limitation. It is hard to > see why we'd need kernel support for this. Because the kernel is a primary TPM user. We can't have the kernel call on the in-userspace resource manager without causing a deadlock, so we need as much of the RM as is needed to support the kernel in the kernel itself. James -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > userspace instance with subsequent relinquishment of privilege. At > > that point one has the freedom to implement all sorts of policy. > > If you look at the patch set that I sent yesterday it exactly has a > feature that makes it more lean for a privileged process to implement > a resource manager. I continue to think, based on comments like this, that you should not implement tmps0 in the first revision either. That is also something we have to live with forever, and it can never become the 'policy limited' or 'unpriv safe' access point to the kernel. ie go back to something based on tmp0 with ioctl. This series should focus on allowing a user space RM to co-exist with the in-kernel services - lets try and tackle the idea of a policy-restricted or unpriv-safe cdev when someone comes up with a comprehensive proposal.. > The current patch set does not define policy. The simple policy > addition that could be added soon is the limit of connections > because it is easy to implement in non-intrusive way. It is also trivial for a userspace RM to limit the number of sessions or connections or otherwise to manage this limitation. It is hard to see why we'd need kernel support for this. The main issue from the kernel perspecitive is how to allow sessions to be used in-kernel and continue to make progress when they start to run out. Jason -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
On Thu, Feb 09, 2017 at 03:06:38AM -0600, Dr. Greg Wettstein wrote: > 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? I doubt it. Personally I would rather just limit the number of connections to /dev/tpms0 than have a complex lease model (like one implemented in this commit). That could have '0' setting, which would disable it so that it doesn't cause harm to those who do not need it. > 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. If you look at the patch set that I sent yesterday it exactly has a feature that makes it more lean for a privileged process to implement a resource manager. > 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. Agreed. > 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. The current patch set does not define policy. The simple policy addition that could be added soon is the limit of connections because it is easy to implement in non-intrusive way. > > > /Jarkko > > Have a good weekend. > > Greg Likewise! /Jarkko -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
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 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "If I'd listened to customers, I'd have given them a faster horse." -- Henry Ford -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
