Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5180406yba; Wed, 10 Apr 2019 13:12:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLQFGr0on1D67XGAoVJh+OVSt11hk9eh1xMCy8QHUtHY1zfzsaEFdVQBo8td6ouoLAbK9N X-Received: by 2002:a65:6389:: with SMTP id h9mr43261144pgv.398.1554927127071; Wed, 10 Apr 2019 13:12:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554927127; cv=none; d=google.com; s=arc-20160816; b=sFIyYzl9oHlbLYlvh6xCMgaPug22Sn7VG8Gxhc+dyOoxysu+s5tYykPnmFZsz7krWL CZacVFPqVkkP6SSmp4ycT7at5pjnBlorhBEsYm4m7+aP3TnnPsspR/+FQUw30Pc2bM9f b7LSA+YvFqdrGnhBGPGA+F0N7/YG6eUlbgwdoldL2xDhTbowTt2dJJoWvmBa46l1tnud uMozptUTpTNzVTdFGbSj8W4SOI3S2LVGRvE2lcUAbOwq+muQyhhnOyxwN99/aF/RYN9A +WHVyUy0oTuNHTmQ642jrixh9dLJ0d50jIjEQQ20h9Qtdqw4IT4JrKznr8yVhd6EC5gV pLMA== 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=XY9FjyJ+WMOx5Fy0wOqfFhJN5cTjZNxcpbDUcZDp5oE=; b=Y0VNteyYzQUSJXPvNkNJwz1nzMvYCb12z8kwxo7P+36kBhLufgGEs9iLbDK+QfRATU HC3et4owtNXaDq7g0VtwUrZ+0A/TGrrptm7fQNQofUWS4+I1QdCTsj7Drjgu1E8YxDE0 yPMYwqUXqzC5fc+Te4JVhzD7RBXEbmCG4fkIlEev1O7Ms+NMUXBhjunORA0gLjWiLT30 C75aOjkotVL06gv40Zt/U7QgDIAKd3tLC/G4JUveGAjMe9MS2SknwqtK+KIIxEIcTEJ5 a69h2EZL09NKvx1rbVR2yKrHdkwwBDndOT1CswxrcJZlNCnAJbcJDBjeJfgGjB4fTQgo 26mg== 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 f10si31891358pgv.589.2019.04.10.13.11.50; Wed, 10 Apr 2019 13:12:07 -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 S1726536AbfDJULQ (ORCPT + 99 others); Wed, 10 Apr 2019 16:11:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:39072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726014AbfDJULP (ORCPT ); Wed, 10 Apr 2019 16:11:15 -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 2C44B2077C; Wed, 10 Apr 2019 20:11:14 +0000 (UTC) Date: Wed, 10 Apr 2019 16:11:12 -0400 From: Steven Rostedt To: "Joel Fernandes (Google)" 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: <20190410161112.540017d9@gandalf.local.home> In-Reply-To: <20190410195708.162185-3-joel@joelfernandes.org> References: <20190410195708.162185-1-joel@joelfernandes.org> <20190410195708.162185-3-joel@joelfernandes.org> 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 15:57:08 -0400 "Joel Fernandes (Google)" wrote: > This series hardens the tracepoints in modules by making the array of > pointers referring to the tracepoints as read-only. This array is needed > during module unloading to verify that the tracepoint is quiescent. > There is no reason for the array to be to be writable after init, and > can cause security or other hidden bugs. Mark these as ro_after_init. > > Suggested-by: paulmck@linux.vnet.ibm.com > Suggested-by: keescook@chromium.org > Suggested-by: mathieu.desnoyers@efficios.com > Cc: rostedt@goodmis.org > Signed-off-by: Joel Fernandes (Google) > --- > kernel/module.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/kernel/module.c b/kernel/module.c > index 8b9631e789f0..be980aaa8804 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3320,6 +3320,12 @@ static const char * const ro_after_init_sections[] = { > * by the SRCU notifiers > */ > "___srcu_struct_ptrs", > + > + /* > + * Array of tracepoint pointers used for checking if tracepoints are > + * quiescent during unloading. > + */ > + "__tracepoints_ptrs", Do we ever modify the __tracepoint_ptrs section? I know the jump_label sections are sorted on load, which means they need to be writable during init, but if __tracepoint_ptrs is not sorted or touched during load, why not just put them in the rodata section to begin with? -- Steve > }; > > static struct module *layout_and_allocate(struct load_info *info, int flags)