tpmdd-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: <Alexander.Steffen@infineon.com>
To: jarkko.sakkinen@linux.intel.com, peterhuewe@gmx.de
Cc: linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net
Subject: RE: [tpmdd-devel] [PATCH RESEND 3/3] tpm-chip: Export TPM device to user space even when startup failed
Date: Thu, 31 Aug 2017 16:26:10 +0000	[thread overview]
Message-ID: <7d87c22c15f64f2da4d73b18ee931e57@MUCSE603.infineon.com> (raw)
In-Reply-To: <20170830111019.bsd2jod7z2v2jeoi@linux.intel.com>

> On Wed, Aug 30, 2017 at 12:41:51PM +0200, Peter Huewe wrote:
> >
> >
> > Am 30. August 2017 12:15:10 MESZ schrieb Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com>:
> > >On Tue, Aug 29, 2017 at 03:17:39PM +0200, Michal Suchánek wrote:
> > >> Hello,
> > >>
> > >> On Tue, 29 Aug 2017 15:55:09 +0300
> > >> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> > >>
> > >> > On Mon, Aug 28, 2017 at 05:15:58PM +0000,
> > >> > Alexander.Steffen@infineon.com wrote:
> > >> > > But is that just because nobody bothered to implement the
> > >necessary
> > >> > > logic or for some other reason?
> > >> >
> > >> > We do not want user space to access broken hardware. It's a huge
> > >risk
> > >> > for system stability and potentially could be used for evil
> > >purposes.
> > >> >
> > >> > This is not going to mainline as it is not suitable for general
> > >> > consumption. You must use a patched kernel if you want this.
> > >> >
> > >> > /Jarkko
> > >> >
> > >>
> > >> It has been pointed out that userspace applications that use direct
> > >IO
> > >> access exist for the purpose. So using a kernel driver is an
> > >> improvement over that if the interface is otherwise sane.
> > >>
> > >> What do you expect is the potential for instability or evil use?
> > >
> > >By definition the use of broken hardware can have unpredictable
> > >effects.
> > >Use a patched kernel if you want to do it.
> >
> > If the s.m.a.r.t selftest of your hard disk fails, you can still
> > access it, even though the hw selftest says it is broken.
> > Same situation.
> 
> Not sure if you can compare these directly although I get your point.
> 
> Waiting for more comments on this. At the moment I'm still dilated to
> restricted access because it gives more variables for the future.
> 
> /Jarkko

I think, this is a perfect example. In both cases we have intelligent devices, that can detect that they are broken and report it correctly (instead of just malfunction randomly). This also shows that those devices are not so broken that they completely misbehave (i.e. significantly violate their spec), they just do not provide the full functionality anymore.

Could you give me one example how you'd imagine such a device to impact stability? My patch already prevents the kernel from using broken TPMs for anything, it only provides the communication facilities for user space applications.

With regard to security/attacks, it is precisely the TPM's job to protect itself (and your secrets). You get all your security guarantees from the TPM, not the driver code, so it does not matter what the driver does, even with a broken TPM.

I understand your point of not wanting to enable functionality that you cannot disable anymore, but I fail to see why you'd ever want to disable (part of) this functionality again. Knowing more about the potential problems would allow me to prevent them from the beginning or to come up with a better safeguard than the command-based whitelisting.

Alexander

  reply	other threads:[~2017-08-31 16:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-24  8:37 [PATCH RESEND 0/3] Export broken TPMs to user space Alexander Steffen
     [not found] ` <20170824083714.10016-1-Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
2017-08-24  8:37   ` [PATCH RESEND 1/3] tpm-chip: Move idr_replace calls to appropriate places Alexander Steffen
2017-08-25 17:25     ` Jarkko Sakkinen
     [not found]       ` <20170825172546.f4bl2wh7tgbyjx2n-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-08-28 17:18         ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
2017-08-24  8:37   ` [PATCH RESEND 2/3] tpm-chip: Return TPM error codes from auto_startup functions Alexander Steffen
     [not found]     ` <20170824083714.10016-3-Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
2017-08-25 17:06       ` Jarkko Sakkinen
     [not found]         ` <20170825170607.wfnr5y5zres2n42r-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-08-29 12:11           ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
2017-08-24  8:37   ` [PATCH RESEND 3/3] tpm-chip: Export TPM device to user space even when startup failed Alexander Steffen
2017-08-25 17:20     ` Jarkko Sakkinen
     [not found]       ` <20170825172021.lw3ycxqw63ubrcm2-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-08-28 17:15         ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
2017-08-29 12:55           ` Jarkko Sakkinen
2017-08-29 13:17             ` [tpmdd-devel] " Michal Suchánek
     [not found]               ` <20170829151739.315ae581-6hIufAJW0g4CVLCxKZUutA@public.gmane.org>
2017-08-29 13:53                 ` Peter Huewe
2017-08-30 10:26                   ` [tpmdd-devel] " Jarkko Sakkinen
2017-08-30 10:15                 ` Jarkko Sakkinen
2017-08-30 10:20                   ` [tpmdd-devel] " Jarkko Sakkinen
2017-08-30 10:34                     ` Michal Suchánek
2017-08-30 11:07                       ` Jarkko Sakkinen
2017-08-31 16:18                         ` Alexander.Steffen
2017-09-02 10:20                           ` Jarkko Sakkinen
     [not found]                   ` <20170830101510.rlkh2p3zecfsrhgl-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-08-30 10:41                     ` Peter Huewe
2017-08-30 11:10                       ` [tpmdd-devel] " Jarkko Sakkinen
2017-08-31 16:26                         ` Alexander.Steffen [this message]
2017-09-02 10:24                           ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d87c22c15f64f2da4d73b18ee931e57@MUCSE603.infineon.com \
    --to=alexander.steffen@infineon.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --subject='RE: [tpmdd-devel] [PATCH RESEND 3/3] tpm-chip: Export TPM device to user space even when startup failed' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).