[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Feb 2020 04:32:45 -0800
From: Kees Cook <keescook@...omium.org>
To: Kristen Carlson Accardi <kristen@...ux.intel.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
arjan@...ux.intel.com, rick.p.edgecombe@...el.com, x86@...nel.org,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH 09/11] kallsyms: hide layout and expose seed
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 <kristen@...ux.intel.com>
> ---
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
