Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5348308yba; Wed, 10 Apr 2019 17:44:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfQaGqNGMNTO/28DyrcJvboHCQsK2L3j1aehaWGGLVu3MzdjFCpWrGklQGPJ08nibHr5nT X-Received: by 2002:a62:1690:: with SMTP id 138mr47351969pfw.28.1554943496133; Wed, 10 Apr 2019 17:44:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554943496; cv=none; d=google.com; s=arc-20160816; b=MgjtwyFcwk2vDXDdl3QcpMnQhdAKXNRmltHfjnw6vnRHPjd2OgiF2SAOti4XAtOu2g WUUftKEWf1bh1MyErOehULtxgYhTowgR2pVc1BelbVn+ljh2se7FciZ/8Oopuq6wxloY EqNC/Q/urxKJ7GUzwMzRSvn3cb+Bq/FrpYpUm+EoT0fyCGxSKpsGQOxQgzuFQJGTLTeK 59947dQHAj7k4SYrQLAokeTzWxwSXoIIH2jUomDgPQmFWRnlqM1qEN+/9eYwbDchOidS C+iap9SGFS2qr3JyDCY8PpKcWJ8klvoC2636gV6XeOy+50br0xa99EhbEw9CZjdFBUvG E1mA== 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=5Xad2K+fanMWyStUqTnfLB6tnCa/oOt3nvfyXjBzEw8=; b=OONXXOOw2MogIDj+n2XYgu0j+scxJjMcZcUqfjXqR6MZb3onDZuFb3a4uwxdXy09bR 9zNzS1WTeaJSVCqhSSCFFU4P0dgSePr8OCkjhXNXCTNrVZKxONMJ52mxNJM2wdYoNRLR kn8ezsfy0xOzC+wsqyfe/HHiBbu4jqZxqtLaQaQs5BSZXNhjbk27GCp1gGjLNtp3iD91 8rdZEJHV0ivKBrZzjY74/8qtdrs+ffoTzVwkNWldUmypAaB0UU38Lv1qj4dQHOLeuEgd eqH1Cm0vHbCeKMlATFZAUm6xZ2KwxBr6Eh9YMS8UiHcm3m3WTWwZ7vJD4BveCAYJZ5W2 7oYg== 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 e3si17862633pgc.98.2019.04.10.17.44.39; Wed, 10 Apr 2019 17:44:56 -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; 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 S1726763AbfDKAoF (ORCPT + 99 others); Wed, 10 Apr 2019 20:44:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:56500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725982AbfDKAoF (ORCPT ); Wed, 10 Apr 2019 20:44:05 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 99BEF2133D; Thu, 11 Apr 2019 00:44:03 +0000 (UTC) Date: Wed, 10 Apr 2019 20:44:01 -0400 From: Steven Rostedt To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, paulmck@linux.vnet.ibm.com, keescook@chromium.org, mathieu.desnoyers@efficios.com, Jessica Yu , kernel-hardening@lists.openwall.com, kernel-team@android.com, rcu@vger.kernel.org Subject: Re: [PATCH v3 3/3] module: Make __tracepoints_ptrs as read-only Message-ID: <20190410204401.62f928ca@gandalf.local.home> In-Reply-To: <20190410202902.GA167446@google.com> References: <20190410195708.162185-1-joel@joelfernandes.org> <20190410195708.162185-3-joel@joelfernandes.org> <20190410161112.540017d9@gandalf.local.home> <20190410202902.GA167446@google.com> X-Mailer: Claws Mail 3.17.3 (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 Wed, 10 Apr 2019 16:29:02 -0400 Joel Fernandes wrote: > The srcu structure pointer array is modified at module load time because the > array is fixed up by the module loader at load-time with the final locations > of the tracepoints right? Basically relocation fixups. At compile time, I > believe it is not know what the values in the ptr array are. I believe same > is true for the tracepoint ptrs array. > > Also it needs to be in a separate __tracepoint_ptrs so that this code works: > > > #ifdef CONFIG_TRACEPOINTS > mod->tracepoints_ptrs = section_objs(info, "__tracepoints_ptrs", > sizeof(*mod->tracepoints_ptrs), > &mod->num_tracepoints); > #endif > > Did I miss some point? Thanks, But there's a lot of others too. Hmm, does this mean that the RO data sections that are in modules are not set to RO? There's a bunch of separate sections that are RO. Just look in include/asm-generic/vmlinux.lds.h under the RO_DATA_SECTION() macro. A lot of the sections saved in module.c:find_module_sections() are in that RO_DATA when compiled as a builtin. Are they not RO when loaded via a module? If this is the case, there probably is going to be a lot more sections added to your list. -- Steve