Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1031819ybg; Wed, 23 Oct 2019 09:22:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwE424ty00fSiFb6yiMKSPVDV21QmMSc4TKgt+QwoubzSDsXBV2GCxkPkZyTDVnswYckYe X-Received: by 2002:a50:ce06:: with SMTP id y6mr38441049edi.259.1571847740417; Wed, 23 Oct 2019 09:22:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571847740; cv=none; d=google.com; s=arc-20160816; b=VgWo6W0QyAvkH5nJVmJ0jDjnvBv+szKGBYmIl7WkMiXVANixmOFn/UZ8VIcHEdPzot +07IyrVqEK4dL50VzFr5SnxDt3GT2Ej2HnABxSH20GRcbGxQOoOneTW6BnP5ShgkRSom ye5lD4En9MlyLNPEMuoUNHQBew4B1bOdyGAdsCJMaKGdBXc3SyUe86CVc8O+fg8jx7Lg dzYbN3NtUG3mIgpp6XEBf1/Nge01It1Cwq5iX02WlrlY9A1kQOUZuZGrXZPcK3hfDGXG PHP5DyWholNS0kjkpJg+E6MD3C2yD3Vr0DoSsWP+T2R7RjN0rYwePd41v9xKdUZ0T/Pk yiDw== 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=9dSEppQA0zukOyOGzSeFOc6C/ThFaH8w34WM1hQFp6A=; b=ofwW/DjBuoos93sgpqXNHSOrxr/5OAHCkP+FyzW51hQXR9h9g6KMLm/I5Gt7RlxNoY gFXtdT8Apdeyhn0sQK22eUqgQM7EhmZm+CCAu1U1qAAaa2qYWP2cgq7DVmZWX7/wxilm Nl9thbfR2cOEL0ZidGtGkat/NXEoE5rEa/oyhC3t5sZyAmupmbe/7VeuK8RDGWIxa4EB PUljdKWNWV+OlYJW+kDBfZlBz48kJu9yrYcOhJpqpLmKryScTAX06TgUYfjYMf9D+xaS CZWArWHoeIIa7qQe/gr13HMy7StfCDVWDrw8DPXT0Kt8qxYrGrsvIaBNQlg0ApznUzD8 vORg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="XgVr/qDH"; 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 qw5si3042313ejb.91.2019.10.23.09.21.56; Wed, 23 Oct 2019 09:22:20 -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="XgVr/qDH"; 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 S2390806AbfJWLs5 (ORCPT + 99 others); Wed, 23 Oct 2019 07:48:57 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:51118 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732092AbfJWLs5 (ORCPT ); Wed, 23 Oct 2019 07:48:57 -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=9dSEppQA0zukOyOGzSeFOc6C/ThFaH8w34WM1hQFp6A=; b=XgVr/qDHNiMu6tpV95rREang4 9vfwCOILKRNAh/pkDIFvyAVcih0R0P0WqO6Q6b381BmA9d8BL51X6bLjrbcE4Orki4HdUyq6G+9BT eyVCW9L+wOw9hn6YTO73aEpH4LSQGf0VqTlnt+UBJBwyU/SZV5nv7Zlw6oFeO4fpbBCX8GKj5NJGU HvLp6xVLLTG14iJnuAfzxJ7nS+62fTWV4WLJiItTnYajHdZl/PcnWq2Cz+dlIgIdwJDu3ivqtUfvX V0R8125e8xZBCG7R8VR9mTsyeIY4v1rFky4eSVIz9m8d5ZWWmBih2qLe4dhKeCQ6HdaTNc7ooD05u tdwPU9cqA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1iNF82-00031x-D9; Wed, 23 Oct 2019 11:48:38 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 9A5F9301224; Wed, 23 Oct 2019 13:47:37 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9418D2B1C6364; Wed, 23 Oct 2019 13:48:35 +0200 (CEST) Date: Wed, 23 Oct 2019 13:48:35 +0200 From: Peter Zijlstra To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mhiramat@kernel.org, bristot@redhat.com, jbaron@akamai.com, torvalds@linux-foundation.org, tglx@linutronix.de, mingo@kernel.org, namit@vmware.com, hpa@zytor.com, luto@kernel.org, ard.biesheuvel@linaro.org, jeyu@kernel.org Subject: Re: [PATCH v4 15/16] module: Move where we mark modules RO,X Message-ID: <20191023114835.GT1817@hirez.programming.kicks-ass.net> References: <20191018073525.768931536@infradead.org> <20191018074634.801435443@infradead.org> <20191021135312.jbbxsuipxldocdjk@treble> <20191021141402.GI1817@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191021141402.GI1817@hirez.programming.kicks-ass.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 Mon, Oct 21, 2019 at 04:14:02PM +0200, Peter Zijlstra wrote: > On Mon, Oct 21, 2019 at 08:53:12AM -0500, Josh Poimboeuf wrote: > > Doesn't livepatch code also need to be modified? We have: > > Urgh bah.. I was too focussed on the other klp borkage :/ But yes, > arm64/ftrace and klp are the only two users of that function (outside of > module.c) and Mark was already writing a patch for arm64. > > Means these last two patches need to wait a little until we've fixed > those. So the other KLP issue: peterz: ad klp, apply_relocate_add() and text_poke()... what about apply_alternatives() and apply_paravirt()? They call text_poke_early(), which was ok with module_disable/enable_ro(), but now it is not, I suppose. See arch_klp_init_object_loaded() in arch/x86/kernel/livepatch.c. mbenes: hurm, I don't see why we would need to do apply_alternatives() / apply_paravirt() later, why can't we do that the moment we load the module mbenes: that is, those things _never_ change after boot peterz: as jpoimboe explained. See commit d4c3e6e1b193497da3a2ce495fb1db0243e41e37 for detailed explanation. Now sadly that commit missed all the useful information, luckily I could find the patch in my LKML folder, more sad, that thread still didn't contain the actual useful information, for that I was directed to github: https://github.com/dynup/kpatch/issues/580 Now, someone is owning me a beer for having to look at github for this. That finally explained that what happens is that the RELA was trying to fix up the paravirt indirect call to 'local_irq_disable', which apply_paravirt() will have overwritten with 'CLI; NOP'. This then obviously goes *bang*. This then raises a number of questions: 1) why is that RELA (that obviously does not depend on any module) applied so late? 2) why can't we unconditionally skip RELA's to paravirt sites? 3) Is there ever a possible module-dependent RELA to a paravirt / alternative site? Now, for 1), I would propose '.klp.rela.${mod}' sections only contain RELAs that depend on symbols in ${mod} (or modules in general). We can fix up RELAs that depend on core kernel early without problems. Let them be in the normal .rela sections and be fixed up on loading the patch-module as per usual. This should also deal with 2, paravirt should always have RELAs into the core kernel. Then for 3) we only have alternatives left, and I _think_ it unlikely to be the case, but I'll have to have a hard look at that. Hmmm ?