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;
Date:   Thu, 21 Nov 2019 13:51:26 -0800
From:   "Luck, Tony" <tony.luck@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Ingo Molnar <mingo@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        H Peter Anvin <hpa@zytor.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by
 kernel parameter
Message-ID: <20191121215126.GA9075@agluck-desk2.amr.corp.intel.com>
References: <1574297603-198156-1-git-send-email-fenghua.yu@intel.com>
 <1574297603-198156-7-git-send-email-fenghua.yu@intel.com>
 <20191121060444.GA55272@gmail.com>
 <20191121130153.GS4097@hirez.programming.kicks-ass.net>
 <20191121131522.GX5671@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191121131522.GX5671@hirez.programming.kicks-ass.net>
User-Agent: Mutt/1.12.1 (2019-06-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 21, 2019 at 02:15:22PM +0100, Peter Zijlstra wrote:
> Also, just to remind everyone why we really want this. Split lock is a
> potent, unprivileged, DoS vector.

So how much do we "really want this"?

It's been 543 days since the first version of this patch was
posted. We've made exactly zero progress.

Current cut down patch series is the foundation to move one
small step towards getting this done.

Almost all of what's in this set will be required in whatever
final solution we want to end up with. Out of this:

 Documentation/admin-guide/kernel-parameters.txt |   10 +++
 arch/x86/include/asm/cpu.h                      |    5 +
 arch/x86/include/asm/cpufeatures.h              |    2 
 arch/x86/include/asm/msr-index.h                |    8 ++
 arch/x86/include/asm/traps.h                    |    3 +
 arch/x86/kernel/cpu/common.c                    |    2 
 arch/x86/kernel/cpu/intel.c                     |   72 ++++++++++++++++++++++++
 arch/x86/kernel/traps.c                         |   22 +++++++
 8 files changed, 123 insertions(+), 1 deletion(-)

the only substantive thing that will *change* is to make the default
be "on" rather than "off".

Everything else we want to do is *additions* to this base. We could
wait until we have those done and maybe see if we can stall out this
series to an even thousand days. Or, we can take the imperfect base
and build incrementally on it.

You've expressed concern about firmware ... with a simple kernel command
line switch to flip, LUV (https://01.org/linux-uefi-validation) could begin
testing to make sure that firmware is ready for the big day when we throw
the switch from "off" to "on".

-Tony