Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1022139imu; Mon, 5 Nov 2018 12:29:41 -0800 (PST) X-Google-Smtp-Source: AJdET5ew8jzcM8i2L8Mcxy9rdFQ1bA6Cfzj3Uxb5vmljcIcXAojb+F9gbLdCb1DN6ebA6iFtxmgU X-Received: by 2002:a63:4044:: with SMTP id n65mr14778716pga.90.1541449781671; Mon, 05 Nov 2018 12:29:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541449781; cv=none; d=google.com; s=arc-20160816; b=ShKgHY6Zu/AHHmb9lntdxhydmPvPTNE2yQ+BaNCQjGO33A9b1iUQIN3gAI1XvQjsf4 +6xC+WJvyF/4pXHSrxJKZLyoqmmQJS9sZvxDidtZyvkRo2gztaS3Lw7dsXzjC5kBeNaT 9Hl9sNcx1yTPb6hYiimxpRcKLBRxClwLT4FzSqyReio8Il2nPqXUjM6vo2datg2A7NAD Bo2S6+FKKRigvmbFHd8YwpXrFAKvPa3ljx8PNIZAcbpKPy5MkOmHvR6ik8dRjnUo0nVg CYxc30pCqNSBZvIaOhwVNI7EPBUFdaUUua+eLCxkipfEwoRpbxen9Iid9yxrAGax2qQm pt9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=NvfsWZ4ObRh59KrySMC5fpYwiqCJXIEOQ3ycZKg1hUA=; b=brYTGkNp91T/+FEteCNRKHP8Ufw6sDYygMJpinNPNbyMhbqf8WSVFS8KaLNENX/wju owMlCyRPyQb4bx069YPC6KAwg6CSHHHun9IHRHlnbLofCqsfU8Yn61WKjTcdIGwIoRsJ dk1lCDMnjTxtenifFvoHQQne5tokfJvE30ZuvQX3+tNyA+dD5FWK7tyVR+hfVoQD6GOE XGkWqj12w3Fr/v6CttGXBIMp+QVeqQj/BeD9bDY7FcwO4+/Gh/bwYn7TtkiV8YVDplgY S9ZJOyGGoXlKxhfo7gfA7vS/K2QKE0XonZlTx9uEt/S9ltw39B5JevxqEF5NaJSJmEk4 X+Og== 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 m6-v6si47254830pfg.282.2018.11.05.12.29.26; Mon, 05 Nov 2018 12:29:41 -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 S1729885AbeKFFuX (ORCPT + 99 others); Tue, 6 Nov 2018 00:50:23 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:35992 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725910AbeKFFuX (ORCPT ); Tue, 6 Nov 2018 00:50:23 -0500 Received: from p5492fe24.dip0.t-ipconnect.de ([84.146.254.36] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gJlU7-0004n6-EB; Mon, 05 Nov 2018 21:28:31 +0100 Date: Mon, 5 Nov 2018 21:28:29 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: Nadav Amit , Linus Torvalds , "H. Peter Anvin" , Peter Zijlstra , Ingo Molnar , LKML , X86 ML , Borislav Petkov , Dave Hansen , Andrew Lutomirski , Kees Cook , Dave Hansen , Masami Hiramatsu Subject: Re: [PATCH v3 2/7] x86/jump_label: Use text_poke_early() during early_init In-Reply-To: Message-ID: References: <20181102232946.98461-1-namit@vmware.com> <20181102232946.98461-3-namit@vmware.com> <20181105140925.GD22467@hirez.programming.kicks-ass.net> <4D260352-A9FF-47F2-B3B2-0A87DF16CB70@vmware.com> <8DF7BED8-F1B2-4102-9452-46437D3E4FC6@vmware.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 5 Nov 2018, Andy Lutomirski wrote: > On Mon, Nov 5, 2018 at 11:25 AM Nadav Amit wrote: > Linus, hpa, or Dave, a question for you: suppose I map some page > writably, write to it, then upgrade permissions to allow execute. > Must I force all CPUs that might execute from it without first > serializing to serialize? I suspect this doesn't really affect user > code, but it may affect the module loader. > > To be safe, shouldn't the module loader broadcast an IPI to > sync_core() everywhere after loading a module and before making it > runnable, regardless of alternative patching? > > IOW, the right sequence of events probably ought to me: > > 1. Allocate the memory and map it. > 2. Copy in the text. > 3. Patch alternatives, etc. This is logically just like (2) from an > architectural perspective -- we're just writing to memory that won't > be executed. > 4. Serialize everything. > 5. Run it! I'd make that: 1. Allocate the memory and map it RW 2. Copy in the text. 3. Patch alternatives, etc. This is logically just like (2) from an architectural perspective -- we're just writing to memory that won't be executed. 4. Map it RX 5. Serialize everything. 6. Run it! Thanks, tglx