All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Matthew Garrett <mjg59@google.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	Kari Hiitola <kari@varaani.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Alexander Steffen <Alexander.Steffen@infineon.com>
Subject: Re: Fixing CVE-2017-15361
Date: Thu, 26 Oct 2017 13:01:15 +0200	[thread overview]
Message-ID: <20171026110115.lyubl22zikwlulhi@linux.intel.com> (raw)
In-Reply-To: <20171025202221.gkgch7rjjqoblzpf@rhwork>

On Wed, Oct 25, 2017 at 01:22:21PM -0700, Jerry Snitselaar wrote:
> On Wed Oct 25 17, Jarkko Sakkinen wrote:
> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists
> > > > vulnerable FW versions. I think this is the only responsible action from
> > > > my side that I can do.
> > > 
> > > I'm not sure this is ideal - do Infineon have any Linux tooling for
> > > performing firmware updates, and if so will that continue working if
> > > the device is blacklisted? It's also a poor user experience to have
> > > systems using TPM-backed disk encryption keys suddenly rendered
> > > unbootable, and making it as easy as possible for people to do an
> > > upgrade and then re-seal secrets with new keys feels like the correct
> > > approach.
> > 
> > I talked today with Alexander Steffen in the KS unconference and we
> > concluded that this would be a terrible idea.
> > 
> > Alexander stated the following things about FW updates (Alexander,
> > please correct me if I state something incorrectly or if you have
> > something to add):
> > 
> > * FW update can be constructed either in a way that the keys in the
> >  NVRAM are not cleared or in a way that they are cleared.
> > * FW update cannot be directly applied to the TPM but must come as
> >  part of the firmware update from the vendor.
> 
> If that is the case, can the two of you get Intel to update the fw
> for the tpm in the nuc5i5myhe (slb9665) :) ? It has needed an update for a while, due
> to issues with context management. My understanding (quite likely I misunderstood)
> from a recent discussion with Peter was that it was possible to update the fw.

I don't know but I can at least forward the complains to the mother ship
:-)

It is fairly intuitive why dTPM cannot be updated without full firmware
update. It's part of the proprietary HW platform, not something
connected through PCI, USB or any standard bus.

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: jarkko.sakkinen@linux.intel.com (Jarkko Sakkinen)
To: linux-security-module@vger.kernel.org
Subject: Fixing CVE-2017-15361
Date: Thu, 26 Oct 2017 13:01:15 +0200	[thread overview]
Message-ID: <20171026110115.lyubl22zikwlulhi@linux.intel.com> (raw)
In-Reply-To: <20171025202221.gkgch7rjjqoblzpf@rhwork>

On Wed, Oct 25, 2017 at 01:22:21PM -0700, Jerry Snitselaar wrote:
> On Wed Oct 25 17, Jarkko Sakkinen wrote:
> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists
> > > > vulnerable FW versions. I think this is the only responsible action from
> > > > my side that I can do.
> > > 
> > > I'm not sure this is ideal - do Infineon have any Linux tooling for
> > > performing firmware updates, and if so will that continue working if
> > > the device is blacklisted? It's also a poor user experience to have
> > > systems using TPM-backed disk encryption keys suddenly rendered
> > > unbootable, and making it as easy as possible for people to do an
> > > upgrade and then re-seal secrets with new keys feels like the correct
> > > approach.
> > 
> > I talked today with Alexander Steffen in the KS unconference and we
> > concluded that this would be a terrible idea.
> > 
> > Alexander stated the following things about FW updates (Alexander,
> > please correct me if I state something incorrectly or if you have
> > something to add):
> > 
> > * FW update can be constructed either in a way that the keys in the
> >  NVRAM are not cleared or in a way that they are cleared.
> > * FW update cannot be directly applied to the TPM but must come as
> >  part of the firmware update from the vendor.
> 
> If that is the case, can the two of you get Intel to update the fw
> for the tpm in the nuc5i5myhe (slb9665) :) ? It has needed an update for a while, due
> to issues with context management. My understanding (quite likely I misunderstood)
> from a recent discussion with Peter was that it was possible to update the fw.

I don't know but I can at least forward the complains to the mother ship
:-)

It is fairly intuitive why dTPM cannot be updated without full firmware
update. It's part of the proprietary HW platform, not something
connected through PCI, USB or any standard bus.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-10-26 11:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25 13:44 Fixing CVE-2017-15361 Jarkko Sakkinen
2017-10-25 13:44 ` Jarkko Sakkinen
2017-10-25 14:17 ` Matthew Garrett
2017-10-25 14:17   ` Matthew Garrett
2017-10-25 18:53   ` Jarkko Sakkinen
2017-10-25 18:53     ` Jarkko Sakkinen
2017-10-25 20:22     ` Jerry Snitselaar
2017-10-25 20:22       ` Jerry Snitselaar
2017-10-26 11:01       ` Jarkko Sakkinen [this message]
2017-10-26 11:01         ` Jarkko Sakkinen
2017-10-25 22:26     ` Peter Huewe
2017-10-25 22:26       ` Peter Huewe
2017-10-26 11:16       ` Jarkko Sakkinen
2017-10-26 11:16         ` Jarkko Sakkinen
2017-10-26 11:27         ` Jarkko Sakkinen
2017-10-26 11:27           ` Jarkko Sakkinen
2017-10-26 12:59         ` Michal Suchánek
2017-10-26 12:59           ` Michal Suchánek
2017-10-26 14:06           ` Jarkko Sakkinen
2017-10-26 14:06             ` Jarkko Sakkinen
2017-10-26 14:06             ` Jarkko Sakkinen
2017-10-26 14:57             ` Michal Suchánek
2017-10-26 14:57               ` Michal Suchánek
2017-10-26 14:57               ` Michal Suchánek
2017-10-26 17:02               ` Jarkko Sakkinen
2017-10-26 17:02                 ` Jarkko Sakkinen
2017-10-26 17:02                 ` Jarkko Sakkinen
2017-10-26 17:03                 ` Jarkko Sakkinen
2017-10-26 17:03                   ` Jarkko Sakkinen
2017-10-26 17:03                   ` Jarkko Sakkinen
2017-10-26 15:46         ` Alexander.Steffen
2017-10-26 15:46           ` Alexander.Steffen at infineon.com
2017-10-26 17:08           ` Jarkko Sakkinen
2017-10-26 17:08             ` Jarkko Sakkinen
2017-10-26 15:42     ` Alexander.Steffen
2017-10-26 15:42       ` Alexander.Steffen at infineon.com
2017-10-26 17:00       ` Jarkko Sakkinen
2017-10-26 17:00         ` Jarkko Sakkinen
2017-10-26 15:51     ` Alexander.Steffen
2017-10-26 15:51       ` Alexander.Steffen at infineon.com
2017-10-26 19:07       ` Jarkko Sakkinen
2017-10-26 19:07         ` 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=20171026110115.lyubl22zikwlulhi@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=Alexander.Steffen@infineon.com \
    --cc=kari@varaani.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mjg59@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.