I was never able to reproduce this issue on Ubuntu 14.04 but, after
reviewing the Spectre V2 mitigations in the 3.13 based 14.04 kernel, I
think the 14.04 kernel could be affected by this bug. Additionally, I
didn't want the decision on when to make use of IBPB to be different in
14.04 than in all
Experiencing freezes on multiple Ubuntu 16.04 LTS desktops of my
organization, all using sssd. Freezes started around April 9th, but we
usually deploy new packages after a time period of 5 to 7 days. I have
experienced freezes with kernels 4.4.0-119, 4.4.40-116 and even
4.4.0-112 on my own
Is a lack of testing for trusty going to prevent a patch for
xenial/artful? We don't have any machines on trusty to test it with, but
if it's going to block the whole patch then we might be able to wipe an
affected machine and install trusty to test it.
--
You received this bug notification
On 04/10/2018 11:43 AM, Janne Snabb wrote:
> I may have experienced this issue also on bionic (18.04) with the
> current kernel version as of today (4.15.0-13.14).
It wouldn't be this same exact bug as the 4.15.0-13.14 kernel doesn't
call __ptrace_may_access() when deciding to make use of IBPB
> I may have experienced this issue also on bionic (18.04) with the
current kernel version as of today (4.15.0-13.14).
I have a system running bionic and it's fine (see #34). Always has been. It's
never run anything else (just over 2 weeks old...). It's always had the "new"
I may have experienced this issue also on bionic (18.04) with the
current kernel version as of today (4.15.0-13.14).
I upgraded one affected system with "do-release-upgrade -d". After
completing the upgrade and rebooting, the system froze the same way as
with the affected 17.10 kernel and
@brad-figg #98:
I've tested the Xenial-proposed kernel on a machine that was previously broken
(even performed a fresh install to this effect). The proposed kernel
(4.13.0-39) fixes the problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is
I've tested the artful kernel on a UEFI system (and tracked own how the
signed kernel is produced from the unsigned on in the debs at he same
time - see #76).
It fixes the issue (tag already changed).
--
You received this bug notification because you are a member of Kernel
Packages, which is
Tested kernel from xenial-proposed on an affected system, and the issue
there appears to be resolved.
$ uname -r
4.4.0-120-generic
$ apt policy linux-image-generic
linux-image-generic:
Installed: 4.4.0.120.126
Candidate: 4.4.0.120.126
Version table:
*** 4.4.0.120.126 400
400
I tested the new kernel in artful-proposed on a system which failed with
the newest kernel + intel-microcode in normal artful repository.
Thus I confirm that the kernel in artful-proposed fixes this issue for
me.
$ apt policy linux-image-4.13.0-39-generic
linux-image-4.13.0-39-generic:
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
artful' to 'verification-done-artful'. If the problem still exists,
change the tag
I wasn't able to reproduce the problem on Trusty, even with sssd
installed.
/proc/version_signature
Ubuntu 4.4.0-119.143~14.04.1-generic 4.4.114
/proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-119-generic
root=UUID=e57a614e-ad1a-449e-954d-ce832d128920 ro quiet splash vt.handoff=7
dmesg -t | grep
HWE Kernel in xenial-testing resolves the issue as well
/proc/version_signature
Ubuntu 4.13.0-39.44~16.04.1-generic 4.13.16
/proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-4.13.0-39-generic
root=UUID=7dcb6f6f-1069-4315-a421-0d60fffecef9 ro rootflags=subvol=@
dmesg -t | grep -i microcode
microcode:
@kleber-souza I don't think that I have anything running trusty that I
can test with, but I can easily test on xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1759920
Title:
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'. If the problem still exists,
change the tag
After purging intel-microcode package the 38 kernel runs for me.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1759920
Title:
intel-microcode 3.20180312.0 causes lockup at login
I uninstalled package intel-microcode and can now use my laptop.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1759920
Title:
intel-microcode 3.20180312.0 causes lockup at login
Thank you, Tyler, your 4.4 kernel has been working great for half a day,
even with the DVB-related patches for my DVB card.
viscacha% cat /proc/version_signature
Ubuntu 4.4.0-119.143+lp1759920.1-generic 4.4.114
viscacha% cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-119-generic
Tyler's amended kernel got me out of a hole today, thanks for the work.
I've told my users not to update kernel until this is in the Ubuntu
repos.
One observation from me is that VirtualBox 5.2.8 causes my HP Z230
(running Ubuntu 16.04.4) to crash and reboot when I try to start a VM.
Not a
Is there any issue with removing the intel-microcode package with the
-38 kernel? The intel-microcode package does not seem to get installed
on a fresh 16.04.4 system and the Spectre/Meltdown checker referenced
earlier shows no vulnerability as the mitigation is all done in the
kernel.
--
You
On 04/05/2018 03:25 PM, QkiZ wrote:
> @Tyler when we should expect this fix in official Ubuntu repository?
A little over 2 weeks from now. The week of April 23rd is the current
target.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
Can confirm test kernal fixed my hard lock issue as well:
/proc/version_signature
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
/proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-4.13.0-38-generic
root=UUID=7dcb6f6f-1069-4315-a421-0d60fffecef9 ro rootflags=subvol=@
dmesg -t | grep -i microcode
@Tyler when we should expect this fix in official Ubuntu repository?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1759920
Title:
intel-microcode 3.20180312.0 causes lockup at login
Thanks @tyhicks.
$ dmesg | grep microcode
[0.00] microcode: microcode updated early to revision 0x1f, date =
2018-02-07
[0.843339] microcode: sig=0x306a9, pf=0x2, revision=0x1f
[0.843412] microcode: Microcode Update Driver: v2.2.
$ cat /proc/version_signature
Ubuntu
I've tested Ty's 4.4 kernel from comment #78 and can confirm it has let me log
in with an LDAP user.
Uname:
Linux M3520 4.4.0-119-generic #143+lp1759920.1 SMP Wed Apr 4 21:32:55 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
version_signature:
Ubuntu 4.4.0-119.143+lp1759920.1-generic 4.4.114
** Changed in: linux (Ubuntu Artful)
Status: In Progress => Fix Committed
** Changed in: linux (Ubuntu Xenial)
Status: In Progress => Fix Committed
** Changed in: linux (Ubuntu Trusty)
Status: In Progress => Fix Committed
--
You received this bug notification because you
** Changed in: linux (Ubuntu Trusty)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu Xenial)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu Artful)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu Trusty)
Importance: Undecided =>
** Description changed:
+ [Impact]
+
+ * Some systems experience kernel lockups after updating to the latest
intel-microcode
+package or when receiving updated microcode from a BIOS update.
+
+ * In many cases, the lockups occur before users can reach the login screen
which makes
+
I can also confirm that the problem doesn't occur with linux-
image-4.13.0-38-generic_4.13.0-38.43+lp1759920.1_amd64.deb
cat /proc/version_signature =>
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
cat /proc/cmdline =>
BOOT_IMAGE=/vmlinuz-4.13.0-38-generic root=/dev/mapper/kubuntu--vg-root ro
@tyhicks
I can also confirm that the issue appears to be resolved with linux-
image-4.13.0-38-generic_4.13.0-38.43+lp1759920.1
Below is the requested information.
$ uname -a
Linux mercury 4.13.0-38-generic #43+lp1759920.1 SMP Tue Apr 3 22:59:23 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
$ cat
@tyhicks
I can confirm that adding 'apparmor=0' to the kernal boot parameters
resolved the issue on an effected system.
This was tested on 4.13.0-37-generic, with intel microcode 3.20180312.0
I will proceed with testing kernel: need linux-
image-4.13.0-38-generic_4.13.0-38.43+lp1759920.1
--
I've been using the test kernel for 17.10 for a few hours, and it works
great!
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
BOOT_IMAGE=/boot/vmlinuz-4.13.0-38-generic
root=UUID=dd134dc1-6642-41d8-acd1-abc83ab24099 ro quiet splash
vt.handoff=7
microcode: microcode updated early to revision
Any affected 16.04 users that are using the 4.4 kernel can find a test
build with the fix here:
https://people.canonical.com/~tyhicks/lp1759920/xenial/
When you provide testing feedback, please remember to include the output
from these commands in your comment:
$ cat /proc/version_signature
$
Works fine.
~ cat /proc/version_signature
Ubuntu 4.13.0-38.43+lp1759920.1-lowlatency 4.13.16
~ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.13.0-38-lowlatency root=/dev/mapper/system-root ro
rootflags=subvol=@ splash
Well, I *think* I can answer my own question about the signed image.
The signed image was *not* generated by my installing the lp1759920 kernel.
In fact it is the identical file to the one from:
My other system (no UEFI) does seem to be OK on this new kernel - and it
is actually running it:
[parent]: cat /proc/version_signature
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
[parent]: cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.13.0-38-generic
root=UUID=ca819911-be41-4822-8720-4536f278aa56
These are the packages I have installed:
root@gmllaptop:/local/configs/packages# dpkg-query -l '*4.13.0-38*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Well, I have a problem testing that kernel.
I've downloaded the linux-image and linux-image extra debs and installed
them with dpkg -i.
Rebooting (with the new microcode) hangs.
But on rebooting and checking /proc/version_signature I see:
Ubuntu 4.13.0-38.43-generic 4.13.16
which makes no sense
@tyhicks
Gargravarr from #ubuntu-kernel :)
Tested your -38 kernel for this issue from comment #67 and I can confirm
it allows me to log in with SSSD and an LDAP user. Outputs for your
requested commands:
1)
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
2)
> Define *old* microcode
The microcode from 3.20180108.0+really20170707ubuntu17.10.1:
[parent]: dmesg -t | grep -i microcode
microcode: microcode updated early to revision 0x29, date = 2013-06-12
microcode: sig=0x206a7, pf=0x2, revision=0x29
microcode: Microcode Update Driver: v2.2.
If Intel
@gordon-lack
>> FWIW: I just ran that on my system with the *old* microcode, and it
Define *old* microcode
Microcode can also come from the latest BIOS if you had updated. So if
you really wanted to be sure you have the original CPU microcode which
should be vulnerable, you will need to:
1.
>> Also ran:
>>
>> https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
FWIW: I just ran that on my system with the *old* microcode, and it
reports "NOT VULNERABLE" for all three variants too.
--
You received this bug notification because you
dijuremo@localhost:~$ cat /proc/version_signature
Ubuntu 4.13.0-38.43+lp1759920.1-generic 4.13.16
dijuremo@localhost:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.13.0-38-generic root=/dev/mapper/aevg-root ro quiet
splash vt.handoff=7
dijuremo@localhost:~$ dmesg -t | grep -i microcode
microcode:
Test kernels with the fix are available here:
http://people.canonical.com/~tyhicks/lp1759920/
You most likely only need linux-
image-4.13.0-38-generic_4.13.0-38.43+lp1759920.1_amd64.deb and linux-
image-extra-4.13.0-38-generic_4.13.0-38.43+lp1759920.1_amd64.deb
You should test that kernel
It was working fine for a few minutes. I opened Firefox, played some
Hulu, opened Android Studio, connected my tablet, and all was well. When
I tried to allow USB debugging on the tablet, the system locked up.
I had been using 4.13.0-37 prior to trying the new microcode again, so
I'll revert the
It works so far with apparmor=0, and jams without it. I'll keep running
it for a while to see if it stays stable.
I used a slightly different method of getting the latest microcode:
sudo apt-mark unhold intel-microcode
sudo apt upgrade
This ran update-initramfs on 4.13.0-38, so everything should
I've since left the 4.13.0-38-generic kernel + 3.20180312 microcode +
apparmor=0 option running for >30 mins (top constantly running plus a
short compilation using all 4 cores in parallel, make -j4, of a github
download).
It still looked OK.
--
You received this bug notification because you are
> if someone affected wanted to boot with the apparmor=0 kernel command
line option (with the latest artful kernel, without the noibpb kernel
command line option, and with the latest intel-microcode package), I'd
really appreciate it.
Just done this:
Downloaded latest microcode (3.20180312).
@tyhicks, I don't have an Artful test system, but I confirmed on Xenial
(4.4.0-116-generic) that `apparmor=0` is a workaround, without the
`noibpb` option and with intel-microcode version
3.20180312.0~ubuntu16.04.1.
--
You received this bug notification because you are a member of Kernel
I think that I've figured out this lockup thanks to some information in
duplicate bugs. Specifically, this comment:
https://bugs.launchpad.net/ubuntu/+source/intel-
microcode/+bug/1760264/comments/7
as well as the nice git bisect work of jsalisbury that I recently
discovered in bug 1746418. This
** Attachment added: "intel-microcode.crash"
https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/+attachment/5100323/+files/intel-microcode.crash
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I had this same problem on a system with an "ASUS H170M-PLUS"
motherboard, a Core i5-6600 CPU, internal graphics and up-to-date Ubuntu
17.10.
Booting into the recovery console worked, but when trying to boot into
the desktop it would always hang somewhere before GDM becomes visible.
After
I can confirm this with the following processor:
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
iucode-tool reports the following signature:
iucode-tool: system has processor(s) with signature 0x000306a9
This
Affects me on:
Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz (family: 0x6, model: 0x5e, stepping:
0x3)
uninstall / disable intel-microcode has restored service on my DL20 G9
server.
Kernel cmdline dis_ucode_ldr worked to allow me to boot and uninstall
the package.
> By any chance, do all of you
>> And adding 'noibpb' kernel boot parameter helps, at least in my case.
However, according to:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls
doing that,
"Disabling these features removes mitigations for CVE-2017-5715 (aka Spectre /
Variant 2).",
It looks like this is the same problem as
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746418. And adding
'noibpb' kernel boot parameter helps, at least in my case.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
> By any chance, do all of you have sssd installed?
No. I don't have it installed on any of my systems, two of which are
affected.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1759920
By any chance, do all of you have sssd installed? One of my colleagues
(Kyle Etsler) has established a relationship between this problem and
having that package installed. I've verified this on my own machine
now, and it makes some sense given that sssd is involved in the login
process.
--
You
This is a similar thread on Arch Linux:
https://bugs.archlinux.org/task/57511
Includes the comment:
"Wasn't the 20180108 microcode update retracted because of issues? Maybe we
should downgrade back to 20171117."
There is no 20180108 download available at Intel now:
>> Well, 4.13.0-32 seems to be unaffected...
Only because it isn't the latest kernel you have, so it has never had
the latest microcode added into it - it will still be loading the
previous (working) version.
--
You received this bug notification because you are a member of Kernel
Packages,
>> Gordon Lack (gordon-lack) wrote 23 hours ago:
>> >> Installing or removing intel-microcode only runs update-initramfs
for the latest kernel
>> I eventually noticed that too.
>> So it means that the problem follows the microcode - nothing to do with the
>> kernel version.
Well, 4.13.0-32
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: intel-microcode (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
>> Installing or removing intel-microcode only runs update-initramfs for
the latest kernel
I eventually noticed that too.
So it means that the problem follows the microcode - nothing to do with the
kernel version.
--
You received this bug notification because you are a member of Kernel
** Description changed:
I don't know if this is a problem with the kernel or the microcode, but
we have a significant number of computers in our organization (on both
16.04 and 17.10) that fail if they have both updated. Booting with
either linux-image-4.13.0-36-generic or
That's very interesting John, that could also explain why we had a system:
1) get updated
2) fail on 4.4.0-116-generic
3) work on 4.4.0-112-generic
4) install 4.13.0-36-generic and 4.13.0-37-generic
5) fail on 4.13.0-36-generic and 4.13.0-37-generic
6) get intel-microcode downgraded to
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: intel-microcode (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
I just found something interesting. Installing or removing intel-microcode only
runs update-initramfs for the latest kernel, which is why my 4.13.0-36-generic
kept working. When I ran
"sudo update-initramfs -u -k 4.13.0-36-generic", that kernel stopped working
too.
--
You received this bug
FYI: These are the signatures for my three systems.
Failing for these on 17.10 (4.13.0-37-generic):
signature 0x000306c3 (and for 4.13.0-38-generic)
signature 0x000206a7
OK for this on 18.04beta (4.15.0-13-generic):
signature 0x000306d4
--
You received this bug notification
Sorry for spamming, but I could not find how to edit my previous comment
- in my case the freeze happened with every boot. Additionally, for some
reason, I was not able to boot KDE Neon from a usb either, and that one
was not used or updated in a while. I was thinking that it's somehow
Hi all,
I'm experiencing the same issue on Linux Mint 18.2 (based on ubuntu
16.04), running 4.13.0-37-generic. I'm using Luks, so after decrypting
my drive(s), the system continues to boot, but never reaches the login
screen.
iucode-tool: system has processor(s) with signature 0x000406e3
Cpu:
It behaves a little differently. Before, it would clear the screen and
get stuck. Now it shows this:
[ 36.067981] watchdog: BUG: soft lockup - CPU#5 stuck for 22s!
[kworker/5:1:71]
[ 36.067983] watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [thermald:1113]
[ 36.527766] NMI watchdog:
For me, on my laptop (Intel(R) Core(TM) i5-4330M CPU @ 2.80GHz) with Kubuntu
17.10, the 4.13.0-38-generic kernel (signed image) has the same problem.
In fact it was slightly worse, a it seems to have wiped out my Ubuntu UEFI
booting (boots straight to Windows - I can get to the Ubuntu menu from
On 03/30/2018 10:59 AM, Gordon Lack wrote:
>> Could someone test out the 4.13.0-38-generic kernel from artful-proposed
>> to see if you experience any lock ups with the 3.20180312.0 microcode?
>
> Any simple install instructions?
Here are the typical install instructions for enabling proposed:
> Could someone test out the 4.13.0-38-generic kernel from artful-proposed
> to see if you experience any lock ups with the 3.20180312.0 microcode?
Any simple install instructions?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
I'm still unable to reproduce these lock ups and I've tested on three
different systems. So, I'm reliant on you (very helpful) bug reporters.
Could someone test out the 4.13.0-38-generic kernel from artful-proposed
to see if you experience any lock ups with the 3.20180312.0 microcode?
In the
Kubuntu 17.10, kernel 4.13.0-37-generic, Dell E6330 with Intel graphics
(iucode-tool: system has processor(s) with signature 0x000306a9, cpuinfo
attached), after intel-microcode upgrade to 3.20180312.0~ubuntu17.10.1
=> lockup during boot after entering disk encryption password but before
login
I've identified a couple more systems that are affected by this issue:
iucode-tool: system has processor(s) with signature 0x00040651
iucode-tool: system has processor(s) with signature 0x000806e9
That second one was actually having trouble with 4.4.0-116-generic
(boots fine with
Bug #1760095 (mine) reports it for two 17.10 systems (Intel graphics only) both
on 4.13.0-37-generic.
An 18.04beta system 4.15.0-13-generic with the "same" microcode version is OK.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
** Summary changed:
- intel-microcode 3.20180312.0 causes locks up at login screen(w/
linux-image-4.13.0-37-generic)
+ intel-microcode 3.20180312.0 causes lockup at login screen(w/
linux-image-4.13.0-37-generic)
--
You received this bug notification because you are a member of Kernel
81 matches
Mail list logo
