Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC] #MC mess
Date:   Wed, 19 Feb 2020 07:20:31 -0800
Message-Id: <49953812-0F54-4809-9DA7-8A6EA0B57A74@amacapital.net>
References: <20200219150507.GD18400@hirez.programming.kicks-ass.net>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Andy Lutomirski <luto@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Tony Luck <tony.luck@intel.com>, x86-ml <x86@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
In-Reply-To: <20200219150507.GD18400@hirez.programming.kicks-ass.net>
To:     Peter Zijlstra <peterz@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 19, 2020, at 7:05 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> =EF=BB=BFOn Wed, Feb 19, 2020 at 09:21:15AM -0500, Steven Rostedt wrote:
>>> On Wed, 19 Feb 2020 09:15:41 +0100
>>> Peter Zijlstra <peterz@infradead.org> wrote:
>>>=20
>>>>>=20
>>>>> Tony, etc, can you ask your Intel contacts who care about this kind of=

>>>>> thing to stop twiddling their thumbs and FIX IT?  The easy fix is
>>>>> utterly trivial.  Add a new instruction IRET_NON_NMI.  It does
>>>>> *exactly* the same thing as IRET except that it does not unmask NMIs.
>>>>> (It also doesn't unmask NMIs if it faults.)  No fancy design work.
>>>>> Future improvements can still happen on top of this. =20
>>>=20
>>> Yes please! Of course, we're stuck with the existing NMI entry crap
>>> forever because legacy, but it would make all things NMI so much saner.
>>=20
>> What would be nice is to have a NMI_IRET, that is defined as something
>> that wont break legacy CPUs. Where it could be just a nop iret, or maybe
>> if possible a "lock iret"? That is, not have a IRET_NON_NMI, as that
>> would be all over the place, but just the iret for NMI itself. As
>> that's in one place.
>=20
> I don't think that matters much; alternatives should be able to deal
> with all that either which way around.

Agreed. That being said, kernels without alternatives could prefer the varia=
nt where a CR4 bit makes regular IRET leave NMIs masked and a new IRET instr=
uction (or LOCK IRET, I suppose) unmasks them.=