APPLIED/cmnt: [PATCH 0/2][SRU][TRUSTY] Fix deadlock on task switches with new microcode
kleber.souza at canonical.com
Thu Apr 5 12:28:02 UTC 2018
On 04/05/18 08:01, Tyler Hicks wrote:
> BugLink: https://bugs.launchpad.net/bugs/1759920
> 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 it very difficult to debug/workaround.
> [Test Case]
> The most reliable test case currently known is to install the sssd package.
> Lockups may occur during package installation (disable IBPB by writing 0 to
> /proc/sys/kernel/ibpb_enabled to prevent this from happening). A lockup will
> most likely occur just after booting the system up as the lock screen is
> [Regression Potential]
> The fix is in the task switching code of the kernel so complexity of the change
> is relatively high.
> [Other Information]
> I couldn't reproduce this issue on Trusty but, after reviewing the code, I
> can't see any reason why it wouldn't also affect Trusty. Additionally, I think
> it makes sense to standardize, across all of our releases, on which condition
> we'll make use of IBPB instead of leaving Trusty to make a ptrace access check
> when all other kernels are doing checks based on if the process is non
> To ease the backport and reduce a chance of regression, I've removed the logic
> in the second patch that doesn't use IBPB when switching from a process, to a
> kernel idle thread, and then back to the original process. This could inflict
> some performance penalty on non-dumpable processes.
Applied patches trusty/master-next branch, adding the CVE
reference to patch 1/2 and the BugLink to patch 2/2.
More information about the kernel-team