Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2203727imu; Thu, 10 Jan 2019 09:59:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN6lH6oACsraglrjuKxPUfliPtRV1X9eqT0IOV3jCxwIC+FhrW7t2TzjD0hD7gRADFuUa/9J X-Received: by 2002:a17:902:20e9:: with SMTP id v38mr10821137plg.250.1547143163320; Thu, 10 Jan 2019 09:59:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547143163; cv=none; d=google.com; s=arc-20160816; b=dgx5Z9OmWFGzyQYCGot5enncWVhaozIqWCJFUKbPknevlRDRZRC7U35hfrVH2kYCm+ VXlPXZlv5OORLHyc2krQdo48QAFysZYgAcW4rMoglUkK8nlovXTyWcLrnnrwhZ+usoEt 5qUQD+7CzcyMWxz25QnT5bY/7QheGksQBen2UnsaL4buahUSlD9tcOHnVAiBVc6rJeQ2 GVl+fEjVPBYosjXzsiCWN8v5+/G+AzwADECwZd0iS2R40oo6QHHxMsTEt/zRtq4bBGBk 4/wybMpjKb874vOgSbbkfKyduGo+RrdxIW8piA0LqlepeeafoHtegh8xJ0ZRMJiUb1HZ +EEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=M3u9fPXgonEWkNTJac1EhFYUePdt/1b1HPh6Yzk0StM=; b=XQKX71ve2VQQbD+3fIgcc0moOoVWHPRhtTfFdgIh0h1ao/YO8DuNQqUR2lx/jediah ttc3//afTIWU0EouiresoBPlHNLdR5QRn+U96r60wr4DItoUcbVKqfAo9EbF6eUKAWzU +2hzCx5j6TI93qONlannQS02XArIIf/kUC7xyqmYxL5uhETnSW6L6p+qwxD/plI8P9Zl q2P5WpL4kB/1vB7ocx9aFfBrcJ5dsDWzKQd/oGl5gXIwdYOz5BtQLaCn8PXD2GKzrN2y wmDbTJW47yXWdHgz2NLU27tbc71P5Es2Dj1PoFAT/CO6zxOhqdh7QFNIhJmMBkg6Zn6C IoPg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o33si8332301pld.121.2019.01.10.09.59.07; Thu, 10 Jan 2019 09:59:23 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730561AbfAJR6C (ORCPT + 99 others); Thu, 10 Jan 2019 12:58:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:59482 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729480AbfAJR6B (ORCPT ); Thu, 10 Jan 2019 12:58:01 -0500 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 14ACE2064C; Thu, 10 Jan 2019 17:57:58 +0000 (UTC) Date: Thu, 10 Jan 2019 12:57:57 -0500 From: Steven Rostedt To: Sean Christopherson Cc: Josh Poimboeuf , Nadav Amit , X86 ML , LKML , Ard Biesheuvel , Andy Lutomirski , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira Subject: Re: [PATCH v3 5/6] x86/alternative: Use a single access in text_poke() where possible Message-ID: <20190110125757.1c8d2870@gandalf.local.home> In-Reply-To: <20190110174257.GE16556@linux.intel.com> References: <279b8003f7f0a6831d090ab822d37bc958f974de.1547073843.git.jpoimboe@redhat.com> <8138A1EE-359D-4CD2-8E96-5BF00313AB3B@vmware.com> <20190110172004.wuh45xoafynfm2df@treble> <20190110123243.3b9e0856@gandalf.local.home> <20190110174257.GE16556@linux.intel.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Jan 2019 09:42:57 -0800 Sean Christopherson wrote: > On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote: > > On Thu, 10 Jan 2019 11:20:04 -0600 > > Josh Poimboeuf wrote: > > > > > > > > While I can't find a reason for hypervisors to emulate this instruction, > > > > smarter people might find ways to turn it into a security exploit. > > > > > > Interesting point... but I wonder if it's a realistic concern. BTW, > > > text_poke_bp() also relies on undocumented behavior. > > > > But we did get an official OK from Intel that it will work. Took a bit > > of arm twisting to get them to do so, but they did. And it really is > > pretty robust. > > Did we (they?) list any caveats for this behavior? E.g. I'm fairly > certain atomicity guarantees go out the window if WC memtype is used. Note, the text_poke_bp() process was this: (nothing to do with atomic guarantees) add breakpoint (one byte) to instruction. Sync all cores (send an IPI to each one). change the back half of the instruction (the rest of the instruction after the breakpoint). Sync all cores Remove the breakpoint with the new byte of the new instruction. What atomicity guarantee does the above require? -- Steve