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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 3E08BC43219 for ; Mon, 29 Apr 2019 22:08:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 15ED12075E for ; Mon, 29 Apr 2019 22:08:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729615AbfD2WIR (ORCPT ); Mon, 29 Apr 2019 18:08:17 -0400 Received: from mga06.intel.com ([134.134.136.31]:37256 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729412AbfD2WIR (ORCPT ); Mon, 29 Apr 2019 18:08:17 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2019 15:08:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,411,1549958400"; d="scan'208";a="166186098" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.181]) by fmsmga004.fm.intel.com with ESMTP; 29 Apr 2019 15:08:15 -0700 Date: Mon, 29 Apr 2019 15:08:15 -0700 From: Sean Christopherson To: Linus Torvalds Cc: Andrew Lutomirski , Steven Rostedt , Peter Zijlstra , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , the arch/x86 maintainers , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , Linux List Kernel Mailing , live-patching@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" Subject: Re: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Message-ID: <20190429220814.GF31379@linux.intel.com> References: <20190427100639.15074-4-nstange@suse.de> <20190427102657.GF2623@hirez.programming.kicks-ass.net> <20190428133826.3e142cfd@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 29, 2019 at 01:16:10PM -0700, Linus Torvalds wrote: > On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds > wrote: > > > > If nmi were to break it, it would be a cpu bug. I'm pretty sure I've > > seen the "shadow stops even nmi" documented for some uarch, but as > > mentioned it's not necessarily the only way to guarantee the shadow. > > In fact, the documentation is simply the official Intel instruction > docs for "STI": > > The IF flag and the STI and CLI instructions do not prohibit the > generation of exceptions and NMI interrupts. NMI interrupts (and > SMIs) may be blocked for one macroinstruction following an STI. > > note the "may be blocked". As mentioned, that's just one option for > not having NMI break the STI shadow guarantee, but it's clearly one > that Intel has done at times, and clearly even documents as having > done so. > > There is absolutely no question that the sti shadow is real, and that > people have depended on it for _decades_. It would be a horrible > errata if the shadow can just be made to go away by randomly getting > an NMI or SMI. FWIW, Lakemont (Quark) doesn't block NMI/SMI in the STI shadow, but I'm not sure that counters the "horrible errata" statement ;-). SMI+RSM saves and restores STI blocking in that case, but AFAICT NMI has no such protection and will effectively break the shadow on its IRET. All other (modern) Intel uArchs block NMI in the shadow and also enforce STI_BLOCKING==0 when injecting an NMI via VM-Enter, i.e. prevent a VMM from breaking the shadow so long as the VMM preserves the shadow info. KVM is generally ok with respect to STI blocking, but ancient versions didn't migrate STI blocking and there's currently a hole where single-stepping a guest (from host userspace) could drop STI_BLOCKING if a different VM-Exit occurs between the single-step #DB VM-Exit and the instruction in the shadow. Though "don't do that" may be a reasonable answer in that case.