From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 493DDC2B9F4 for ; Fri, 25 Jun 2021 10:41:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2C27A61446 for ; Fri, 25 Jun 2021 10:41:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbhFYKoL (ORCPT ); Fri, 25 Jun 2021 06:44:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbhFYKoI (ORCPT ); Fri, 25 Jun 2021 06:44:08 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2052FC061574 for ; Fri, 25 Jun 2021 03:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=0YdS37bI2y8yslvpmOBaU88Z5WMSHVVAjXFi6JVaeVI=; b=hM54jayk2zsWxSINWFnjVr+UKe P2mroc1MdkXOEi0qbeteeu1Ef8xLWtpezfiAOjjSnUbgaJsMAGPr2O72nVEsJ/pV4XK1k9tbS0lOn Okj5CCH2QNHlMBKocR4MIxlkZs3HWEx153WcdLZHDNiDQbSy9ibAHFVZ5Re76QA+hR+uAgpink5Jj rg3eoaOmGlo365SgFywfnFD8jjCYAn/p/Q/GG5ClXeRtxI2hR61d9f1u0MxtwSgMzLMLTGvwW/94C 6LuKDjgcowHa1raAPkBauYRjMx20ck2c+nikDopvWPsbYQC7zppFvxV9Vjure88AtQc97m/B9YsDp CVC81ugw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwjGZ-00HaEQ-Ts; Fri, 25 Jun 2021 10:41:00 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 34788300233; Fri, 25 Jun 2021 12:40:53 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 18D162019DA0B; Fri, 25 Jun 2021 12:40:53 +0200 (CEST) Date: Fri, 25 Jun 2021 12:40:53 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: Thomas Gleixner , Lai Jiangshan , Linux Kernel Mailing List , Steven Rostedt , Lai Jiangshan , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "H. Peter Anvin" , Juergen Gross , Al Viro , Arvind Sankar Subject: Re: [RFC PATCH 1/4] x86/entry/nmi: Switch to the entry stack before switching to the thread stack Message-ID: References: <20210601065217.23540-1-jiangshanlai@gmail.com> <20210601065217.23540-2-jiangshanlai@gmail.com> <87bl81h3ih.ffs@nanos.tec.linutronix.de> <444d7139-e47a-4831-93d0-8eb5b9680fdc@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <444d7139-e47a-4831-93d0-8eb5b9680fdc@www.fastmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 19, 2021 at 08:13:15PM -0700, Andy Lutomirski wrote: > > > On Sat, Jun 19, 2021, at 3:51 PM, Thomas Gleixner wrote: > > On Tue, Jun 01 2021 at 14:52, Lai Jiangshan wrote: > > > From: Lai Jiangshan > > > > > > Current kernel has no code to enforce data breakpoint not on the thread > > > stack. If there is any data breakpoint on the top area of the thread > > > stack, there might be problem. > > > > And because the kernel does not prevent data breakpoints on the thread > > stack we need to do more complicated things in the already horrible > > entry code instead of just doing the obvious and preventing data > > breakpoints on the thread stack? > > Preventing breakpoints on the thread stack is a bit messy: it’s > possible for a breakpoint to be set before the address in question is > allocated for the thread stack. How about we call into C from the entry stack and have the from-user stack swizzle there. The from-kernel entries land on the ISTs and those are already excluded. > None of this is NMI-specific. #DB itself has the same problem. We > could plausibly solve it differently by disarming breakpoints in the > entry asm before switching stacks. I’m not sure how much I like that > approach. I'm not sure I see how, from-user #DB already doesn't clear DR7, and if we recurse, we'll get a from-kernel trap, which will land on the IST, whcih is excluded, and then we clear DR7 there. IST and entry stack are excluded, the only problem we have is thread stack, and that can be solved by calling into C from the entry stack. I should put teaching objtool about .data references from .noinstr.text and .entry.text higher on the todo list I suppose ...