[Query] ARM64 kaslr support - randomness, seeding and kdump
AKASHI Takahiro
takahiro.akashi at linaro.org
Thu Apr 5 19:09:50 PDT 2018
Bhupesh,
On Fri, Mar 16, 2018 at 03:05:10PM +0530, Bhupesh Sharma wrote:
> On Wed, Mar 14, 2018 at 11:54 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Wed, Mar 14, 2018 at 11:10:53AM +0900, AKASHI Takahiro wrote:
> >> If kaslr-seed has a critical value in terms of security, is kexec-tools
> >> a right place? It is exposed to user space albeit for a short time of period.
> >
> > The kernel zeroes the seed in the DT at boot time, so the current seed
> > isn't visible to userspace.
> >
> > If kexec-tools generates a seed, and inserts it into the DTB that it
> > loads, this is only visible to kexec tools or other applications which
> > can inspect its memory, so I don't think this is much of a concern.
> > Anything with such privilege can presumably kexec() to arbitrary code
> > anyhow.
> >
> > The next kernel will then zero its seed in the DT at boot time, so
> > similarly this won't be visible to userspace on the new kernel.
> >
> > FWIW, having kexec tools generate a seed for the kexec_load() case makes
> > sense to me.
>
> Fair enough. I will try to take a stab at the same and come back with
> my findings on this thread.
How's your progress here?
I've already added kaslr support (i.e. "virtual randomisation") to
my kexec_file patch set.
# just a few lines of code, though
-Takahiro AKASHI
> Thanks,
> Bhupesh
More information about the kexec
mailing list