linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Kristen Carlson Accardi <kristen@linux.intel.com>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	arjan@linux.intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com, rick.p.edgecombe@intel.com,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH v2 8/9] kallsyms: Hide layout
Date: Thu, 21 May 2020 14:14:08 -0700	[thread overview]
Message-ID: <202005211409.3C314DF@keescook> (raw)
In-Reply-To: <20200521165641.15940-9-kristen@linux.intel.com>

On Thu, May 21, 2020 at 09:56:39AM -0700, Kristen Carlson Accardi wrote:
> This patch makes /proc/kallsyms display alphabetically by symbol
> name rather than sorted by address in order to hide the newly
> randomized address layout.
> 
> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> Tested-by: Tony Luck <tony.luck@intel.com>
> ---
>  kernel/kallsyms.c | 138 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 137 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index 16c8c605f4b0..558963b275ec 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -25,6 +25,7 @@
>  #include <linux/filter.h>
>  #include <linux/ftrace.h>
>  #include <linux/compiler.h>
> +#include <linux/list_sort.h>
>  
>  /*
>   * These will be re-linked against their real values
> @@ -446,6 +447,11 @@ struct kallsym_iter {
>  	int show_value;
>  };
>  
> +struct kallsyms_iter_list {
> +	struct kallsym_iter iter;
> +	struct list_head next;
> +};
> +
>  int __weak arch_get_kallsym(unsigned int symnum, unsigned long *value,
>  			    char *type, char *name)
>  {
> @@ -660,6 +666,121 @@ int kallsyms_show_value(void)
>  	}
>  }
>  
> +static int sorted_show(struct seq_file *m, void *p)
> +{
> +	struct list_head *list = m->private;
> +	struct kallsyms_iter_list *iter;
> +	int rc;
> +
> +	if (list_empty(list))
> +		return 0;
> +
> +	iter = list_first_entry(list, struct kallsyms_iter_list, next);
> +
> +	m->private = iter;
> +	rc = s_show(m, p);
> +	m->private = list;
> +
> +	list_del(&iter->next);
> +	kfree(iter);
> +
> +	return rc;
> +}
> +
> +static void *sorted_start(struct seq_file *m, loff_t *pos)
> +{
> +	return m->private;
> +}
> +
> +static void *sorted_next(struct seq_file *m, void *p, loff_t *pos)
> +{
> +	struct list_head *list = m->private;
> +
> +	(*pos)++;
> +
> +	if (list_empty(list))
> +		return NULL;
> +
> +	return p;
> +}
> +
> +static const struct seq_operations kallsyms_sorted_op = {
> +	.start = sorted_start,
> +	.next = sorted_next,
> +	.stop = s_stop,
> +	.show = sorted_show
> +};
> +
> +static int kallsyms_list_cmp(void *priv, struct list_head *a,
> +			     struct list_head *b)
> +{
> +	struct kallsyms_iter_list *iter_a, *iter_b;
> +
> +	iter_a = list_entry(a, struct kallsyms_iter_list, next);
> +	iter_b = list_entry(b, struct kallsyms_iter_list, next);
> +
> +	return strcmp(iter_a->iter.name, iter_b->iter.name);
> +}
> +
> +int get_all_symbol_name(void *data, const char *name, struct module *mod,
> +			unsigned long addr)
> +{
> +	unsigned long sym_pos;
> +	struct kallsyms_iter_list *node, *last;
> +	struct list_head *head = (struct list_head *)data;
> +
> +	node = kmalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node)
> +		return -ENOMEM;
> +
> +	if (list_empty(head)) {
> +		sym_pos = 0;
> +		memset(node, 0, sizeof(*node));
> +		reset_iter(&node->iter, 0);
> +		node->iter.show_value = kallsyms_show_value();
> +	} else {
> +		last = list_first_entry(head, struct kallsyms_iter_list, next);
> +		memcpy(node, last, sizeof(*node));
> +		sym_pos = last->iter.pos;
> +	}
> +
> +	INIT_LIST_HEAD(&node->next);
> +	list_add(&node->next, head);
> +
> +	/*
> +	 * update_iter returns false when at end of file
> +	 * which in this case we don't care about and can
> +	 * safely ignore. update_iter() will increment
> +	 * the value of iter->pos, for ksymbol_core.
> +	 */
> +	if (sym_pos >= kallsyms_num_syms)
> +		sym_pos++;
> +
> +	(void)update_iter(&node->iter, sym_pos);
> +
> +	return 0;
> +}
> +
> +static int kallsyms_sorted_open(struct inode *inode, struct file *file)
> +{
> +	int ret;
> +	struct list_head *list;
> +
> +	list = __seq_open_private(file, &kallsyms_sorted_op, sizeof(*list));
> +	if (!list)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(list);
> +
> +	ret = kallsyms_on_each_symbol(get_all_symbol_name, list);
> +	if (ret != 0)
> +		return ret;
> +
> +	list_sort(NULL, list, kallsyms_list_cmp);
> +
> +	return 0;
> +}
> +
>  static int kallsyms_open(struct inode *inode, struct file *file)
>  {
>  	/*
> @@ -704,9 +825,24 @@ static const struct proc_ops kallsyms_proc_ops = {
>  	.proc_release	= seq_release_private,
>  };
>  
> +static const struct proc_ops kallsyms_sorted_proc_ops = {
> +	.proc_open = kallsyms_sorted_open,
> +	.proc_read = seq_read,
> +	.proc_lseek = seq_lseek,
> +	.proc_release = seq_release_private,
> +};
> +
>  static int __init kallsyms_init(void)
>  {
> -	proc_create("kallsyms", 0444, NULL, &kallsyms_proc_ops);
> +	/*
> +	 * When fine grained kaslr is enabled, we need to
> +	 * print out the symbols sorted by name rather than by
> +	 * by address, because this reveals the randomization order.
> +	 */
> +	if (!IS_ENABLED(CONFIG_FG_KASLR))
> +		proc_create("kallsyms", 0444, NULL, &kallsyms_proc_ops);
> +	else
> +		proc_create("kallsyms", 0444, NULL, &kallsyms_sorted_proc_ops);
>  	return 0;

Since this is compile-time selected, instead of the separate name and
test here, how about just redefine kallsyms_open initializer instead?

#ifdef CONFIG_FG_KASLR
...sorting routines...
static int kallsyms_open(struct inode *inode, struct file *file)
{ ... sorted version ... }
#else
static int kallsyms_open(struct inode *inode, struct file *file)
{ ... normal version ... }
#endif

(And then just move the comment to the sorted open version.)

-- 
Kees Cook

  reply	other threads:[~2020-05-21 21:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 16:56 [PATCH v2 0/9] Function Granular KASLR Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 1/9] objtool: Do not assume order of parent/child functions Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 2/9] x86: tools/relocs: Support >64K section headers Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 3/9] x86/boot: Allow a "silent" kaslr random byte fetch Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 4/9] x86: Makefile: Add build and config option for CONFIG_FG_KASLR Kristen Carlson Accardi
2020-05-21 20:00   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 5/9] x86: Make sure _etext includes function sections Kristen Carlson Accardi
2020-05-21 18:11   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 6/9] x86/tools: Add relative relocs for randomized functions Kristen Carlson Accardi
2020-05-21 19:54   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 7/9] x86: Add support for function granular KASLR Kristen Carlson Accardi
2020-05-21 21:08   ` Kees Cook
2020-05-21 21:42     ` Kristen Carlson Accardi
2020-06-04 17:27     ` Kristen Carlson Accardi
2020-06-04 22:37       ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 8/9] kallsyms: Hide layout Kristen Carlson Accardi
2020-05-21 21:14   ` Kees Cook [this message]
2020-05-21 16:56 ` [PATCH v2 9/9] module: Reorder functions Kristen Carlson Accardi
2020-05-21 21:33   ` Kees Cook
2020-06-09 20:14     ` Kristen Carlson Accardi
2020-06-09 20:42       ` Kees Cook
2020-06-09 20:59         ` Kristen Carlson Accardi
2020-05-21 21:54 ` [PATCH v2 0/9] Function Granular KASLR Kees Cook
2020-05-21 22:26 ` Thomas Gleixner
2020-05-21 23:30   ` Kees Cook
2020-05-21 23:43     ` Thomas Gleixner
2020-05-21 23:44     ` Kristen Carlson Accardi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202005211409.3C314DF@keescook \
    --to=keescook@chromium.org \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).