[PATCH 0/2][SRU][TRUSTY] Fix deadlock on task switches with new microcode

[Tyler Hicks]

BugLink: https://bugs.launchpad.net/bugs/1759920

[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 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
displayed.

[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
dumpable.

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.