Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1550738
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager |
| Date | 2017-01-04 13:50 +0100 |
| Message-ID | <sVTaW-4JG-3@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <sViEq-4AZ-7@gated-at.bofh.it> <sViEq-4AZ-5@gated-at.bofh.it> <sVxN8-78b-19@gated-at.bofh.it> <sVAhX-xZ-3@gated-at.bofh.it> <sVF7Y-3Mr-23@gated-at.bofh.it> |
| Organization | Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo |
On Tue, Jan 03, 2017 at 02:47:02PM -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote: > > > > I'm not sure about this. Why you couldn't have a very thin daemon > > > that prepares the file descriptor and sends it through UDS socket to > > > a client. > > > > So I'm a bit soured on daemons from the trousers experience: tcsd > > crashed regularly and when it did it took all the TPM connections down > > irrecoverably. I'm not saying we can't write a stateless daemon to fix > > most of the trousers issues, but I think it's valuable first to ask the > > question, "can we manage without a daemon at all?" I actually think > > the answer is "yes", so I'm interested in seeing how far that line of > > research gets us. > > There is clearly no need for a daemon to be involved when working on > simple tasks like key load and key sign/enc/dec actions, adding such a > thing only increases the complexity. > > If we discover a reason to have a daemon down the road then it should > work in some way where the user space can call out to the daemon over > a different path than the kernel. (eg dbus or something) > > > Do you have a link to the presentation? The Plumbers etherpad doesn't > > contain it. I've been trying to work out whether a properly set up TPM > > actually does need any protections at all. As far as I can tell, once > > you've set all the hierarchy authorities and the lockout one, you're > > pretty well protected. > > 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'm not against considering TPM 1.2 support but getting both in the same patch set would be too much. > > So, in general, I'd prefer to see the unprivileged char dev hard > prevented by the kernel from doing certain things: > > - Wipe the TPM > - Manipulate the SRK, nvram, tpm flags, change passwords etc > - Read back the EK > - Write to PCRs > - etc. I rather have an ioctl where you can supply a list of CCs that you want to allow a client to do. /Jarkko > Even if TPM 2 has a stronger password based model, I still think the > kernel should hard prevent those sorts of actions even if the user > knows the TPM password. > > Realistically people in less senstive environments will want to use > the well known TPM passwords and still have reasonable safety in their > unprivileged accounts. > > Jason
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-03 22:50 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-01-03 23:50 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-04 01:20 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-01-04 01:40 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-04 02:00 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-01-04 14:00 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-01-04 16:00 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-01-04 20:10 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-04 20:30 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-04 20:30 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-01-04 00:30 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-01-04 13:50 +0100
Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Ken Goldman <kgoldman@us.ibm.com> - 2017-01-04 15:00 +0100
csiph-web