From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Peter Huewe <peterhuewe@gmx.de>
Cc: 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:27:31 +0200 [thread overview]
Message-ID: <20171026112731.64d6d4qoz25bay4u@linux.intel.com> (raw)
In-Reply-To: <20171026111632.g6a3bkhe4nxorfbm@linux.intel.com>
On Thu, Oct 26, 2017 at 01:16:32PM +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 26, 2017 at 12:26:10AM +0200, Peter Huewe wrote:
> >
> >
> > Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>:
> > >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.
> > >
> > >I proposed the following as an alternative:
> > >
> > >* Print a message to the klog (which log level would be appropriate?).
> > Info?
> > Maybe warn, definitely not err
>
> Since the driver does not fail usually warn would make sense but since
> here even allowing to continue to use such TPM is questionable I would
> use error here.
>
> People anyway ignore klog too easily so using warn would be a mistake in
> my opinion. It's like saying that nothing serious is happening here,
> move along.
>
> Do you think so?
>
> > >* Possibly sleep for few seconds. Is this a good idea?
> > Helps how?
>
> Obviously to get it noticed that the system integrity is broken.
>
> > >While writing this email yet another alternative popped into my mind:
> > >what if we allow only in-kernel use but disallow the use of /dev/tpm0?
> > >You could still use trusted keys.
> > >
> > No, same terrible idea since you block the upgrade path.
> > Upgrade tools work from userspace via the kernel driver.
> > So /dev/tpm0 is necessary.
>
> Right! How stupid of me (my previous response to Jerry) :-) Of course you
> can have special commands and talk to the TPM to do the upgrade even if
> it is part of the platform and not connected to a standard bus.
>
> I got understanding in the yesterdays unconfernce discussion that it
> should be part of the firmware upgrade.
>
> How do you do the upgrade through /dev/tpm0?
>
> /Jarkko
I received the following email for iavael@iavael.name:
<quote>
Hello,
I'm writing regarding you mail in tpm fw update discussion from Wed, 25 Oct
2017 20:53:49 +0200.
Found it in lkml archive and cannot forward it to myself (captcha is broken),
so I cannot join discussion in maillist and writing directly.
There's a tool infineon-firmware-updater (found with tricky google-fu)
Here's an archive
https://gsdview.appspot.com/chromeos-localmirror/distfiles/infineon-firmware-updater-1.1.2459.0.tar.gz
And here are some patches and ebuild file
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/chromeos-base/infineon-firmware-updater/
> * 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.
As far as I understand, this tool requires clearing TPM.
> * FW update cannot be directly applied to the TPM but must come as
> part of the firmware update from the vendor.
Some vendors mentioned here
https://www.infineon.com/cms/en/product/promopages/tpm-update/
distribute infineon's update tool for windows (actually 2 variants of it: CLI
and GUI).
Looks like Google got source code of it's *nix variant.
</quote>
/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:27:31 +0200 [thread overview]
Message-ID: <20171026112731.64d6d4qoz25bay4u@linux.intel.com> (raw)
In-Reply-To: <20171026111632.g6a3bkhe4nxorfbm@linux.intel.com>
On Thu, Oct 26, 2017 at 01:16:32PM +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 26, 2017 at 12:26:10AM +0200, Peter Huewe wrote:
> >
> >
> > Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>:
> > >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.
> > >
> > >I proposed the following as an alternative:
> > >
> > >* Print a message to the klog (which log level would be appropriate?).
> > Info?
> > Maybe warn, definitely not err
>
> Since the driver does not fail usually warn would make sense but since
> here even allowing to continue to use such TPM is questionable I would
> use error here.
>
> People anyway ignore klog too easily so using warn would be a mistake in
> my opinion. It's like saying that nothing serious is happening here,
> move along.
>
> Do you think so?
>
> > >* Possibly sleep for few seconds. Is this a good idea?
> > Helps how?
>
> Obviously to get it noticed that the system integrity is broken.
>
> > >While writing this email yet another alternative popped into my mind:
> > >what if we allow only in-kernel use but disallow the use of /dev/tpm0?
> > >You could still use trusted keys.
> > >
> > No, same terrible idea since you block the upgrade path.
> > Upgrade tools work from userspace via the kernel driver.
> > So /dev/tpm0 is necessary.
>
> Right! How stupid of me (my previous response to Jerry) :-) Of course you
> can have special commands and talk to the TPM to do the upgrade even if
> it is part of the platform and not connected to a standard bus.
>
> I got understanding in the yesterdays unconfernce discussion that it
> should be part of the firmware upgrade.
>
> How do you do the upgrade through /dev/tpm0?
>
> /Jarkko
I received the following email for iavael at iavael.name:
<quote>
Hello,
I'm writing regarding you mail in tpm fw update discussion from Wed, 25 Oct
2017 20:53:49 +0200.
Found it in lkml archive and cannot forward it to myself (captcha is broken),
so I cannot join discussion in maillist and writing directly.
There's a tool infineon-firmware-updater (found with tricky google-fu)
Here's an archive
https://gsdview.appspot.com/chromeos-localmirror/distfiles/infineon-firmware-updater-1.1.2459.0.tar.gz
And here are some patches and ebuild file
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/chromeos-base/infineon-firmware-updater/
> * 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.
As far as I understand, this tool requires clearing TPM.
> * FW update cannot be directly applied to the TPM but must come as
> part of the firmware update from the vendor.
Some vendors mentioned here
https://www.infineon.com/cms/en/product/promopages/tpm-update/
distribute infineon's update tool for windows (actually 2 variants of it: CLI
and GUI).
Looks like Google got source code of it's *nix variant.
</quote>
/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
next prev parent reply other threads:[~2017-10-26 11:27 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
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 [this message]
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=20171026112731.64d6d4qoz25bay4u@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 \
--cc=peterhuewe@gmx.de \
/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.