linux-kernel - Re: [PATCH 0/5] x86/speculation: Disable IBRS when idle

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]

Date:   Mon, 19 Jun 2023 10:47:17 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Robin Jarry <rjarry@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H.Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Joe Mario <jmario@...hat.com>
Subject: Re: [PATCH 0/5] x86/speculation: Disable IBRS when idle

On Sun, Jun 18, 2023 at 11:25:29PM -0400, Waiman Long wrote:

> > We were testing on the RHEL9.2 kernel which doesn't have your

Then keep the tinkering in the RHEL tree, please.

> We may need to extend your current solution to cover more cases.

See below.

> Perhaps adding a module parameter (e.g. idle_no_ibrs) to force the use
> of intel_idle_ibrs(). BTW, is it really the case that we can't disable
> IBRS when irq is enabled?

No, that is an entirely artificial constraint due to not having
intel_idle_ibrs_irq() and having no desire to deal with the
ramifications of such a thing.

That said; it also doesn't make any sense what so ever to add this. The
reason for having this intel_idle_irq() is for C1 state to improve IRQ
response latency. Adding WRMSRs will obviously regress that.

Specifically, we very intentionally did not add CPUIDLE_FLAG_IBRS to the
very shallow idle states to avoid regressions. These WRMSRs are
*EXPENSIVE*.

Additionally, if you were to go do this with IRQs enabled, then you have
to worry about enabling IBRS again on the interrupt path from kernel.

> The idle thread does not really interact with any user
> applications. I don't think there is any risk of information leakage even if
> we disable IBRS with interrupt enabled. Is my assumption incorrect?

Yes:

 - doing the WRMSR on C1 makes no sense, the C1 state is only picked if
   the idle time expectation is *VERY* short, the WRMSR overhead in that
   case is probably more than the expected idle time.

 - doing the WRMSR with IRQs enabled means you now get to touch the
   interrupt/exception from kernel paths, nobody wants more of this
   crap.

 - the whole IBRS thing is a trainwreck, let it be.

 - finally, T0 runs userspace, T1 goes into C1 idle, disables IBRS,
   enables IRQs, takes an IRQ and now T0 can 'see' everything T1 does in
   kernel space, you loose.

Also, did I say that IBRS sucks? Like really? It is horrific -- step
away and let it be.

The possibly better solution is to make sure nothing untrusted what so
ever runs on the DPDK machine, then you can forget about all the
mitigation nonsense.