linux-kernel - Re: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180120152229.GA2042@redhat.com>
Date:   Sat, 20 Jan 2018 16:22:29 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Hou Tao <houtao1@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "qiuxishi@...wei.com" <qiuxishi@...wei.com>,
        "wangkefeng.wang@...wei.com" <wangkefeng.wang@...wei.com>
Subject: Re: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under
 x86_64 host machine

Hello everyone,

On Sat, Jan 20, 2018 at 01:56:08PM +0000, Van De Ven, Arjan wrote:
> well first of all don't use IBRS, use retpoline

This issue triggers in the IBPB code during user to user context
switch and IBPB is still needed there no matter if kernel is using
retpolines or if it uses kernel IBRS. In fact IBPB is still needed
there even if retpolines+user_ibrs is used or if
always_ibrs/ibrs_enabled=2 is used (IBRS doesn't protect from the
poison generated in the same predictor mode, "especially" in future
CPUs).

Only retpolining all userland would avoid IBPB here, but I doubt you
suggest that.

Kernel retpolines or kernel IBRS would make zero difference for
this specific issue.

> and if Andrea says this was a known issue in their code then I think that closes the issue.
> 

It's an implementation bug we inherited from the merge of a CPU vendor
patch and I can confirm it's already closed. The fix has been already
shipped with the wave 2 update in fact and some other versions even
had the bug fixed since the very first wave on 0day.

That deadlock nuisance only ever triggered in artificial QA testcases
and even then it wasn't easily reproducible.

We already moved the follow ups in vendor BZ to avoid using bandwidth
here.

Thank you!
Andrea