[Bug 1700373] Re: intel-microcode is out of date, version 20170707 fixes errata on 6th and 7th generation platforms
Robie Basak
1700373 at bugs.launchpad.net
Tue Jul 25 08:43:13 UTC 2017
Hi Dave,
Thank you for going through this. I think it's OK if you want to keep
the set of dat files available in sync with the set available in the
development release. But then the changelog entry should make this
clear.
I expected the changelog entry to match the diff that I was reviewing.
When users view the entry, they would then expect the entry to match
what they are about to receive (be it source or binaries).
For backports it's often easier to base the changelog on one from the
version that's being backported and add one further entry explaining the
backport. In this case my previous paragraph would still be accurate:
the user would see all the changes landing in the stable release, and
reviewers would also see a diff that corresponded to them.
However we have agreed that this update will be a cherry-pick, not a
backport, so this wouldn't apply anyway.
> ...I thought about not including the debian changelog entry in the x
upload, but I like to error on the side of more information, and this
vvvvvv part of the changelog entry matches identically to zesty and
artful.
I agree with the sentiment. More information is fine. However inaccurate
or misleading information is not. So by all means use the information in
the changelog entry from Artful as a starting point, but you do need to
remove or correct parts that no longer apply.
Given that we aren't backporting the packaging from Artful, I don't
think it makes sense to include lines like "source: remove unneeded
intel-ucode/ directory". As far as I can find, this isn't happening at
all to users, neither in Xenial nor Zesty, and isn't represented in the
diff. I can't find this directory in any sources anywhere (just looking
at Ubuntu).
> If you deem it crucially important...
It's hardly crucially important, but I do think it's reasonable to
expect that the changelog is accurate against what is actually going on,
I think it's reasonable for users to expect this too, and I believe it's
the SRU team's job to maintain this standard.
Please correct as follows (or discuss further if you want to do
something else):
1) Remove the comment about removing intel-ucode/, as I can't see that
in the diff anywhere.
2) Fix or replace "remove superseded upstream data file" so what
whatever you do say matches against what I see in each proposed diff
(you can say something different for Xenial and Zesty if needed of
course). If you're removing dats I think we do need to mention it.
Saying something like "source: remove firmware dat files as needed to
bring the shipped set in sync with those shipped in Artful" would be
fine.
3) In general, make sure that the changelogs accurately describe the
diffs that I will review.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to intel-microcode in Ubuntu.
https://bugs.launchpad.net/bugs/1700373
Title:
intel-microcode is out of date, version 20170707 fixes errata on 6th
and 7th generation platforms
Status in intel-microcode package in Ubuntu:
Fix Released
Status in intel-microcode source package in Trusty:
Won't Fix
Status in intel-microcode source package in Xenial:
Confirmed
Status in intel-microcode source package in Yakkety:
Confirmed
Status in intel-microcode source package in Zesty:
Confirmed
Status in intel-microcode source package in Artful:
Fix Released
Bug description:
[Impact]
* A security fix has been made available as part of intel-microcode
* It is advisable to apply it
* Thus an SRU of the latest intel-microcode is desirable for all stable releases
[Test Case]
* Upgrade intel-microcode package, if it is already installed / one is
running on Intel CPUs
* Reboot and verify no averse results, and/or that microcode for your
cpu was loaded as expected.
[Test case reporting]
* Please paste the output of:
dpkg-query -W intel-microcode
grep -E 'model|stepping' /proc/cpuinfo | sort -u
journalctl -k | grep microcode
[Regression Potential]
Microcode are proprietary blobs, and can cause any number of new errors and regressions. Microcode bugs have been reported before, therefore longer than usual phasing and monitoring of intel-microcode bugs should be done with extra care.
[Other]
caml discussion describing test case to reproduce the crash.
https://caml.inria.fr/mantis/view.php?id=7452
* I did not backport the full debian/changelog, as some of the changes
were ommitted for SRU purposes, and I don't like the idea of modifying
the changelog of others.
* I did not backport this below change but I feel as though the SRU team should evaluate including it. I left it out due to the change as little as possible guidance from the SRU team. Additionally we have already been shipping the microcode version that included this change for a long time. More information here
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00030&languageid=en-fr
'''
# 0x206c2: Intel Westmere B1 (Xeon 3600, 5600, Core i7 2nd gen).
#
# When Intel released a fix for Intel SA-00030, they issued a MCU that
# bumps the minimum acceptable version of the Intel TXT ACMs in the
# TPM persistent storage. This permanently blacklists the vulnerable
# ACMs *even on older microcode* in order to make it somewhat harder
# to work around the security fix through a BIOS downgrade attack.
#
# It is possible that such a microcode update, when peformed by the
# operating system, could sucessfully trigger the TPM persistent
# storage update Intel intended to happen during firmware boot: we
# simply don't know enough to rule it out. Should that happen, Intel
# TXT will be permanently disabled. This could easily interact very
# badly with the firmware, rendering the system unbootable. If *that*
# happens, it would likely require either a TPM module replacement
# (rendering sealed data useless) or a direct flash of a new BIOS with
# updated ACMs, to repair.
#
# Blacklist updates for signature 0x206c2 as a safety net.
IUC_EXCLUDE += -s !0x206c2
'''
* I versioned the packages 3.20170511.1~ubuntu<release> as I feel this
more appropriately reflects the contents of each package rather than
simply incrementing the ubuntu version number.
=========================================================================
[Original bug report]
NB: I am *not* directly affected by this bug.
Henrique emailed a warning to Debian devel today [1] on a potentially
serious issue with (sky|kaby)lake processors. Excerpt:
"This warning advisory is relevant for users of systems with the Intel
processors code-named "Skylake" and "Kaby Lake". These are: the 6th and
7th generation Intel Core processors (desktop, embedded, mobile and
HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
well as select Intel Pentium processor models.
TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem. Read this advisory for instructions about an Intel-provided
fix."
It is probably a good idea to:
(1) issue a warning to our users about this;
(2) update intel-microcode on all our supported releases
I leave the discussion on whether this can have security implications
to others.
[1] https://lists.debian.org/debian-devel/2017/06/msg00308.html
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: intel-microcode 3.20161104.1
ProcVersionSignature: Ubuntu 4.10.0-24.28-generic 4.10.15
Uname: Linux 4.10.0-24-generic x86_64
ApportVersion: 2.20.4-0ubuntu4.1
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Sun Jun 25 10:14:19 2017
InstallationDate: Installed on 2017-05-26 (30 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: intel-microcode
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1700373/+subscriptions
More information about the foundations-bugs
mailing list