[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18da71ef-8586-400f-ae71-6d471f2fedcb@intel.com>
Date: Mon, 23 Oct 2023 15:45:41 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Jonathan Corbet <corbet@....net>,
Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>, tony.luck@...el.com,
ak@...ux.intel.com, tim.c.chen@...ux.intel.com,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
kvm@...r.kernel.org,
Alyssa Milburn <alyssa.milburn@...ux.intel.com>,
Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
antonio.gomez.iglesias@...ux.intel.com
Subject: Re: [PATCH 2/6] x86/entry_64: Add VERW just before userspace
transition
On 10/23/23 15:30, Pawan Gupta wrote:
>>>>> /*
>>>>> * iretq reads the "iret" frame and exits the NMI stack in a
>>>>> * single instruction. We are returning to kernel mode, so this
>>>> This isn't needed here. This is the NMI return-to-kernel path.
>>> Yes, the VERW here can be omitted. But probably need to check if an NMI
>>> occuring between VERW and ring transition will still execute VERW after
>>> the NMI.
>> That window does exist, though I'm not sure it's worth worrying about.
> I am in favor of omitting the VERW here, unless someone objects with a
> rationale. IMO, precisely timing the NMIs in such a narrow window is
> impractical.
I'd bet that given the right PMU event you could make this pretty
reliable. But normal users can't do that by default. That leaves the
NMI watchdog which (I bet) you can still time, but which is pretty low
frequency.
Are there any other NMI sources that a normal user can cause problems with?
Let's at least leave a marker in here that folks can grep for:
/* Skip CLEAR_CPU_BUFFERS since it will rarely help */
and some nice logic in the changelog that they can dig out if need be.
But, basically it sounds like the logic is:
1. It's rare to get an NMI after VERW but before returning to userspace
2. There is no known way to make that NMI less rare or target it
3. It would take a large number of these precisely-timed NMIs to mount
an actual attack. There's presumably not enough bandwidth.
Anything else?
Powered by blists - more mailing lists