Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2602947ybi; Mon, 17 Jun 2019 07:33:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqykXDzhGyNGTEi9cg5Izi1qd+Q2iGKp3Vu3ov/Zg3/BK1mHHlfI40fLO56/pdK2IxZP9ajZ X-Received: by 2002:a65:5344:: with SMTP id w4mr49026962pgr.8.1560782007507; Mon, 17 Jun 2019 07:33:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560782007; cv=none; d=google.com; s=arc-20160816; b=Z2US47FB9HLRryPzQq1SHnt4Act4iB3IDfhXO2/HIr4jEHLIq0nDf2v9LIbiFgtFr+ Rj92icFCq/GNTYhlGnVKUcXX04FdAiaRwo380fUC92jB4oUgvQ3mN/UrGu5LCr0p7EEc VbqGt+hl+q9CeQD2w4yUOQPJTLVgnJbE7O3kblRnlNwXYsiydPfuIk8J2F553O2biEVr O843joY13KWMHDcBp7moQbkJBVBDmOfPk5cj+UMox90D8Bg9xmfoScpThyNh9xeXVTLQ 772qIfkRFD766GTAR+bpclOGL8shpxwHcfHErSPSVmQ2KomlcQNX5USzSZ1TAXSnMrNL Lamw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=NFJYXlUzdjtOs435zT2VUCTTaFwwk1bDij2QZYtv7Eo=; b=av6GbpvlyGFReI+i1Udfmb53mkt7FnYdp8Glh2s+eZzkKLlD8ccwVSaJ4LNB6T+Jc4 YZZKabxkbIMt3gr91OcGEMN1pC13Y9eTfB9Srxe6rI7+vNMvmkYPo3MaaLbzruIWn+DB SLsSs3j4s3VVEIZ/xNAhWJ4ji5E+GSiuGtZZh0LiMlfao9Wpp145+B8oODLHBKScza3e EV4VicbEZYazp4Z8OxX7CiPReGX1XO7h+3EuLbrl34ddTEj6w9bCMf8YFJguRJnc/HXz 3/6WyW9eWfZRVF2SjnVhfq6qfwLtkG2Yyu+NXyMYX8KgJt7N4aZflVKns2omZrRa/NQ3 MRAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=WVPiV4Ro; 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 w7si9916882ply.279.2019.06.17.07.33.11; Mon, 17 Jun 2019 07:33:27 -0700 (PDT) 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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=WVPiV4Ro; 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 S1728301AbfFQObm (ORCPT + 99 others); Mon, 17 Jun 2019 10:31:42 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:48316 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbfFQObm (ORCPT ); Mon, 17 Jun 2019 10:31:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NFJYXlUzdjtOs435zT2VUCTTaFwwk1bDij2QZYtv7Eo=; b=WVPiV4RoKw5OElXExsulkvelC I9ISaJTiqb4jKOqgu2cPZ9SOftWInZsm0TejjW7YtdMwZ4Z83MigsmuNETW25QvlGfnLIaNFMDJas ffWnXGYj/G52wdxf4iHhlPu1CQJykfjcsiOutiHslh17VubxroBb+mIyunb5gt4fT1Aw10uQmjqIX k6vANgk5iXa8iwlpMOvJ6ma6LAB5+6pS7QenrYP4LVqshx5SVSYj46P1VTvQcyTaosPv2dPCAiPIQ oT+P4fF432GZPBnIBibhQRWpZ/zJQRZQNj/WJOHsgfG4r8OW/r32Os6vJUdITZGI0xrtRb9eC9p1V yOaQ9d+AA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.92 #3 (Red Hat Linux)) id 1hcsf9-0003Wb-LN; Mon, 17 Jun 2019 14:31:12 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 29EA4201F45FA; Mon, 17 Jun 2019 16:31:10 +0200 (CEST) Date: Mon, 17 Jun 2019 16:31:10 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: Masami Hiramatsu , x86@kernel.org, linux-kernel@vger.kernel.org, Ard Biesheuvel , Andy Lutomirski , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Nadav Amit , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira Subject: Re: [PATCH 08/15] x86/alternatives: Teach text_poke_bp() to emulate instructions Message-ID: <20190617143110.GD3436@hirez.programming.kicks-ass.net> References: <20190605130753.327195108@infradead.org> <20190605131945.005681046@infradead.org> <20190608004708.7646b287151cf613838ce05f@kernel.org> <20190607173427.GK3436@hirez.programming.kicks-ass.net> <3DA961AB-950B-4886-9656-C0D268D521F1@amacapital.net> <20190611080307.GN3436@hirez.programming.kicks-ass.net> <435093E5-6FE3-4DAA-9ABE-EB9D372F8CF8@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435093E5-6FE3-4DAA-9ABE-EB9D372F8CF8@amacapital.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 11, 2019 at 08:54:23AM -0700, Andy Lutomirski wrote: > > On Jun 11, 2019, at 1:03 AM, Peter Zijlstra wrote: > > arch_optimize_kprobe() then does the text_poke_bp() that replaces the > > instruction @addr with int3, copies the rel jump address and overwrites > > the int3 with jmp. > > > > And I'm thinking the problem is with something like: > > > > @addr: nop nop nop nop nop > > > > We copy out the nops into the trampoline, overwrite the first nop with > > an INT3, overwrite the remaining nops with the rel addr, but oops, > > another CPU can still be executing one of those NOPs, right? > > > > I'm thinking we could fix this by first writing INT3 into all relevant > > instructions, which is going to be messy, given the current code base. > > How does that help? If RIP == x+2 and you want to put a 5-byte jump > at address x, no amount of 0xcc is going to change the fact that RIP > is in the middle of the jump. What I proposed was doing 0xCC on every instruction that's inside of [x,x+5). After that we do machine wide IPI+SYNC. So if RIP is at x+2, then it will observe 0xCC and trigger the exception there. Now, the problem is that my exception cannot recover from anything except NOPs, so while it could work for some corner cases, it doesn't work for the optkprobe case in general. Only then do we write the JMP offset and again to IPI+SYNC; then we write the 0xE8 and again IPI-SYNC. But at that point we already have the guarantee nobody is inside [x,x+5). That is, except if we can get to x+2 without first going through x, IOW if x+2 is a branch target we're screwed any which way around and the poke is never valid. Is that something optkprobes checks? If so, where and how?