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

[Kleber Souza]

On 04/05/18 08:01, Tyler Hicks wrote:
> 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.
> 
> 

Applied patches trusty/master-next branch, adding the CVE
reference to patch 1/2 and the BugLink to patch 2/2.

Thanks,
Kleber