From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: kernel-hardening@lists.openwall.com,
Laura Abbott <labbott@fedoraproject.org>
Subject: Re: [kernel-hardening] initcall randomization
Date: Wed, 12 Oct 2016 00:40:22 +0100 [thread overview]
Message-ID: <20161011234021.GA16858@remoulade> (raw)
In-Reply-To: <CAKv+Gu-LUZOCAYLi+DvNmuVjMC_0OMjZKkCu8+XfH_Z7RQbifQ@mail.gmail.com>
On Tue, Oct 11, 2016 at 07:28:46PM +0100, Ard Biesheuvel wrote:
> vmalloc and ioremap calls will simply be served bottom up, which is
> why the beginning of the vmalloc area mostly looks the same between
> boots, i.e., all non-kaslr boots look identical, and all kaslr boots
> look identical with little variation.
>
> I am aware that random vmalloc is a bad idea,
I must confess ignorance here; what problems does random vmalloc pose in
particular?
> hence my suggestion to perhaps randomize during the __init phase. I
> must admit that this is simply me holding the randomization hammer and
> looking for things that vaguely resemble nails, hence my request for
> discussion rather than proposing patches.
Do we have a particular threat model this helps with?
Is it similar to that for SLUB freelist randomization?
Do we have vmalloc area sepcific information leaks?
Thanks,
Mark.
next prev parent reply other threads:[~2016-10-11 23:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-05 17:09 [kernel-hardening] initcall randomization Ard Biesheuvel
2016-10-05 19:43 ` [kernel-hardening] " Mark Rutland
2016-10-05 20:23 ` [kernel-hardening] " Greg KH
2016-10-05 20:30 ` Kees Cook
2016-10-05 21:45 ` Ard Biesheuvel
2016-10-10 22:17 ` Kees Cook
2016-10-11 18:28 ` Ard Biesheuvel
2016-10-11 19:59 ` Kees Cook
2016-10-12 8:50 ` Ard Biesheuvel
2016-10-11 23:40 ` Mark Rutland [this message]
2016-10-12 8:55 ` Ard Biesheuvel
2016-10-12 20:19 ` Kees Cook
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=20161011234021.GA16858@remoulade \
--to=mark.rutland@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@fedoraproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.