Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1578301
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion |
| Date | 2017-02-10 09:50 +0100 |
| Message-ID | <t9f3Z-140-35@gated-at.bofh.it> (permalink) |
| References | <t8STM-4gx-27@gated-at.bofh.it> <t8STM-4gx-25@gated-at.bofh.it> <t8YPv-7PX-9@gated-at.bofh.it> <t92gr-1CS-33@gated-at.bofh.it> |
| Organization | Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo |
On Thu, Feb 09, 2017 at 12:04:26PM -0700, Jason Gunthorpe wrote: > 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. With /dev/tpms0 I'm fairly certain that it is right way to go as it does make sense to have it as close as being drop in replacement for /dev/tpm0 as possible. There's factors more certainty that the API is something that most people will like to have. > 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.. Sure. I do agree with this. > > 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 This is an issue but in the current patch set there's nothing that would make it harder to sort out. /Jarkko
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion "Dr. Greg Wettstein" <greg@wind.enjellic.com> - 2017-02-09 10:10 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-02-09 16:30 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-09 20:10 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-09 20:40 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-09 23:30 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-02-10 09:50 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-09 20:30 +0100
Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-09 21:20 +0100
csiph-web