Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1481989ybv; Thu, 6 Feb 2020 04:59:14 -0800 (PST) X-Google-Smtp-Source: APXvYqxuYPIsHyjPXe2q9JBEvQPmJQpgxSlDrXSbwAazMiXTyM8QvWDHZiub0q9fxZsdZlZVegoZ X-Received: by 2002:aca:2806:: with SMTP id 6mr6405181oix.64.1580993954600; Thu, 06 Feb 2020 04:59:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580993954; cv=none; d=google.com; s=arc-20160816; b=jZzWvxutBLRV5iu8jYrT+mfzHlTNhFcNMAHlzGK/BPsLiN6A4/BoIX+9rY++/rWu5p r93e+uFffZNeLGRS6D0Z1ppQBZyPqpaAyeDYC58HNmagfbOaLJyMCWckv7nUCbM3C5qQ 3Os/kjzUYxsm4jgjBKebe8ToayAXp5uLg1dA6tZEs1A5SFyVs84Nw3Wsk18ZKpjrdzgD PIjc1vTFJ/EqflQH+w/CE0GhCPTA8qKBaVWMQ6/S3huZWdyX/9Bx2ecvoibAgiBRGse1 3ORneKaed0ieNlhEO8+r3B23OV7xlpRFcAWIFOuipEF2Y7brHb4v7/0UOlBVUCc2TZrs ZNNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=iLM+7gqdqC3q396oekNhXmeqeD/6nzSHAkgAw8RRcxI=; b=OT0jfbW8cAQC7vn/5Cjsf1FcSO50pa1NPdK25xsVW397FBmUXvQ+aRhCdITcj65fKI oYJMx+80tTJZKA6ERCB4E2Sdzts8U8AE4gPG5MhAvUIWlee2ZaOrgnMe9BIYvEFET0La MXkBIR3UhL+cHvKrZJsDnBtnTUSOW+8Xw1AKyF06t0WWCEqDZu11IGG4pRRUyX6vSQvj gGHox0r90r/RIW1xfHwECbZoJ8HUGtDJHTn6VZNjlVBIhRN57LhKANKFEUEWd4f3LWvN pJ/bYhZTkFoAqaFyO3FjaJ+KsKg57QxQyCegg6lS+S5MTd4ci8KloSSDMKeKqfLzWfDA S+hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=IKGkaEps; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f23si1756102oto.205.2020.02.06.04.59.02; Thu, 06 Feb 2020 04:59:14 -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; dkim=pass header.i=@chromium.org header.s=google header.b=IKGkaEps; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727833AbgBFMct (ORCPT + 99 others); Thu, 6 Feb 2020 07:32:49 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:37358 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727361AbgBFMct (ORCPT ); Thu, 6 Feb 2020 07:32:49 -0500 Received: by mail-ot1-f65.google.com with SMTP id d3so5303835otp.4 for ; Thu, 06 Feb 2020 04:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iLM+7gqdqC3q396oekNhXmeqeD/6nzSHAkgAw8RRcxI=; b=IKGkaEpsAEhkpEYCecxs9GUUfuL6q0mDPlCzadw0HhY3rPXN9CL5BBAWqteJekBDK6 gHdUv4wAoxpNB9mRPtDrnGP/QTjlnOBxGVh5GEs5vXFlsfiAcEbbg45BRs9B906ssBHp dxLSSFSB/85Jd0J8zOwY6flBEvzL43fj7aNIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iLM+7gqdqC3q396oekNhXmeqeD/6nzSHAkgAw8RRcxI=; b=e4fj/Dux/wu0IRvDHdGx3831J/+32dFubONslPDEXCbb9+6fBdnCFcJKyNyPR7vuwN bqtWT/4sD7+HXnGc6cX2uEPl7W9WT53far4/1yo+7VW2ljwfe3kBLlv6vXJ7b/YCeR1d NftYrSwx0V5AHUQZh+QDrQZ5Bu5M3NNFw2bXSTC6RoZCeJdCKCgegfNFfzLdvOOsbRaH ZrNz/f4uwJODSOJWfwlZ+wNKZwfOlkooW1V/LpL+NcyWk3BpX8JNIvpzGGNsUq1AFErv eFFVdO5HuVqZjAdPcMHp9zTMq3tRsh23medjW0VXOmRVMam0SaMsLIgHNa4UjVzGSMF5 bbGQ== X-Gm-Message-State: APjAAAVCUodix7/V8yEi/aNK+wPqob2m9pYLppOH89QboM4tliNF8qd4 iaTJhVOxrA2O+CKciWtVAWo0nw== X-Received: by 2002:a05:6830:1050:: with SMTP id b16mr30676098otp.140.1580992367936; Thu, 06 Feb 2020 04:32:47 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id m68sm875700oig.50.2020.02.06.04.32.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2020 04:32:47 -0800 (PST) Date: Thu, 6 Feb 2020 04:32:45 -0800 From: Kees Cook To: Kristen Carlson Accardi Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, arjan@linux.intel.com, rick.p.edgecombe@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [RFC PATCH 09/11] kallsyms: hide layout and expose seed Message-ID: <202002060428.08B14F1@keescook> References: <20200205223950.1212394-1-kristen@linux.intel.com> <20200205223950.1212394-10-kristen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200205223950.1212394-10-kristen@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 05, 2020 at 02:39:48PM -0800, Kristen Carlson Accardi wrote: > To support finer grained kaslr (fgkaslr), we need to make a couple changes > to kallsyms. Firstly, we need to hide our sorted list of symbols, since > this will give away our new layout. Secondly, we will export the seed used > for randomizing the layout so that it can be used to make a particular > layout persist across boots for debug purposes. > > Signed-off-by: Kristen Carlson Accardi > --- > kernel/kallsyms.c | 30 +++++++++++++++++++++++++++++- > 1 file changed, 29 insertions(+), 1 deletion(-) > > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > index 136ce049c4ad..432b13a3a033 100644 > --- a/kernel/kallsyms.c > +++ b/kernel/kallsyms.c > @@ -698,6 +698,21 @@ const char *kdb_walk_kallsyms(loff_t *pos) > } > #endif /* CONFIG_KGDB_KDB */ > > +#ifdef CONFIG_FG_KASLR > +extern const u64 fgkaslr_seed[] __weak; > + > +static int proc_fgkaslr_show(struct seq_file *m, void *v) > +{ > + seq_printf(m, "%llx\n", fgkaslr_seed[0]); > + seq_printf(m, "%llx\n", fgkaslr_seed[1]); > + seq_printf(m, "%llx\n", fgkaslr_seed[2]); > + seq_printf(m, "%llx\n", fgkaslr_seed[3]); > + return 0; > +} > +#else > +static inline int proc_fgkaslr_show(struct seq_file *m, void *v) { return 0; } > +#endif > + I'd like to put the fgkaslr seed exposure behind a separate DEBUG config, since it shouldn't be normally exposed. As such, its infrastructure should be likely extracted from this and the main fgkaslr patches and added back separately (and maybe it will entirely vanish once the RNG is switched to ChaCha20). > static const struct file_operations kallsyms_operations = { > .open = kallsyms_open, > .read = seq_read, > @@ -707,7 +722,20 @@ static const struct file_operations kallsyms_operations = { > > static int __init kallsyms_init(void) > { > - proc_create("kallsyms", 0444, NULL, &kallsyms_operations); > + /* > + * When fine grained kaslr is enabled, we don't want to > + * print out the symbols even with zero pointers because > + * this reveals the randomization order. If fg kaslr is > + * enabled, make kallsyms available only to privileged > + * users. > + */ > + if (!IS_ENABLED(CONFIG_FG_KASLR)) > + proc_create("kallsyms", 0444, NULL, &kallsyms_operations); > + else { > + proc_create_single("fgkaslr_seed", 0400, NULL, > + proc_fgkaslr_show); > + proc_create("kallsyms", 0400, NULL, &kallsyms_operations); > + } > return 0; > } > device_initcall(kallsyms_init); > -- > 2.24.1 In the past, making kallsyms entirely unreadable seemed to break weird stuff in userspace. How about having an alternative view that just contains a alphanumeric sort of the symbol names (and they will continue to have zeroed addresses for unprivileged users)? Or perhaps we wait to hear about this causing a problem, and deal with it then? :) -- Kees Cook