Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2180951imu; Thu, 10 Jan 2019 09:34:18 -0800 (PST) X-Google-Smtp-Source: ALg8bN5K8nv1UOzqxcKUwnxSF5Z+GvmvRLGZbo8dZCDehyF82MGXSlx2PbamWQVEe7rNqSCdhMOP X-Received: by 2002:a62:520b:: with SMTP id g11mr11235225pfb.53.1547141658654; Thu, 10 Jan 2019 09:34:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547141658; cv=none; d=google.com; s=arc-20160816; b=MNE5UzyxeXLx1V/NcVRhm5gcxwbGCpqcfQRSM41Kyj5fisBwOqpwWBnMJjDs7/L4gg gyxBlJDAucLOIhPote0KIxItEDr4u3ltndRlBW1ycJih2rLHw7Yfuj5cJb7YYnZXDxiS t/xnAKhTQqacOKGYcDXBaygn7hvLaLuTyafmLaaI0fvRFqbp3nljQEvb0n47EWyK8q42 aFrFbsk3qeKU3mb1+U72MyOmEIxwSS7gm7WEicnSMhbqDmHG7LIUwoJvJEsEJRkE+1pD owExC2vKpj/SqJWtBEOYRlhMqIjyQC7VJLRSd/D01TAtKP4mDsDIQP5KJw817uaNiHc5 9JvA== 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=ye5uDDSldqW1t5Wt6QqsaCQP3wW6p9lJM2ZXLIwUoAg=; b=WcWeoolN9gnTc91PmGzQVxG992JVCILyrTJuEoHwXBjvexOgswoQI6mSogxxvlhfjf uFmLqWa6UYZm8Iv7T0RAvWQ4FEpFoZ1y3gXNhNraSLNZO+Qf4TFll4MRQqOQChZLhG+Z +hiLjKA5ay2hIhWkCfwgq13ROAyhYqJ8y9HYSXAF7a1CKGUOs6mWVFw3kyZc1a4V3Ukt TnQNSUtRZ3l34/+zkSJM/4uASFoI0delUwsdF3QhxHeyycXXxPa5RHf91mvKHACeEhHz GIoaOrl8/flHbFKAimq5IYLofAyWAetUi2AIJNIM8U0qelBtMeSoT1vy+ONrHlTKxX4P XxjA== 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 w11si7021242pgf.452.2019.01.10.09.34.03; Thu, 10 Jan 2019 09:34:18 -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 S1730375AbfAJRcr (ORCPT + 99 others); Thu, 10 Jan 2019 12:32:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:46774 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730023AbfAJRcr (ORCPT ); Thu, 10 Jan 2019 12:32:47 -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 E8FC220675; Thu, 10 Jan 2019 17:32:44 +0000 (UTC) Date: Thu, 10 Jan 2019 12:32:43 -0500 From: Steven Rostedt To: Josh Poimboeuf Cc: 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: <20190110123243.3b9e0856@gandalf.local.home> In-Reply-To: <20190110172004.wuh45xoafynfm2df@treble> References: <279b8003f7f0a6831d090ab822d37bc958f974de.1547073843.git.jpoimboe@redhat.com> <8138A1EE-359D-4CD2-8E96-5BF00313AB3B@vmware.com> <20190110172004.wuh45xoafynfm2df@treble> 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 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. I would really like an acknowledgment from the HW vendors before we do go this route. -- Steve > > The entire instruction doesn't need to be read atomically; just the > 32-bit call destination. Assuming the hypervisor is x86-64, and it uses > a 32-bit access to read the call destination (which seems logical), the > intra-cacheline reads will be atomic, as stated in the SDM. > > If the above assumptions are not true, and the hypervisor reads the call > destination non-atomically (which seems unlikely IMO), even then I don't > see how it could be realistically exploitable. It would just oops from > calling a corrupt address. >