All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Bhupesh SHARMA <bhupesh.linux@gmail.com>,
	kexec@lists.infradead.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
Date: Fri, 6 Apr 2018 11:09:50 +0900	[thread overview]
Message-ID: <20180406020948.GE19607@linaro.org> (raw)
In-Reply-To: <CACi5LpNyx5VKO6mYB1yXNPENPKhAfAJ7cUSBeVzVtXfF6+EPwg@mail.gmail.com>

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@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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [Query] ARM64 kaslr support - randomness, seeding and kdump
Date: Fri, 6 Apr 2018 11:09:50 +0900	[thread overview]
Message-ID: <20180406020948.GE19607@linaro.org> (raw)
In-Reply-To: <CACi5LpNyx5VKO6mYB1yXNPENPKhAfAJ7cUSBeVzVtXfF6+EPwg@mail.gmail.com>

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@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

  reply	other threads:[~2018-04-06  2:09 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12 20:14 [Query] ARM64 kaslr support - randomness, seeding and kdump Bhupesh Sharma
2018-03-12 20:14 ` Bhupesh Sharma
2018-03-12 20:58 ` Ard Biesheuvel
2018-03-12 20:58   ` Ard Biesheuvel
2018-03-13  1:54   ` Dave Young
2018-03-13  1:54     ` Dave Young
2018-03-13 10:22   ` AKASHI Takahiro
2018-03-13 10:22     ` AKASHI Takahiro
2018-03-13 10:47     ` Mark Rutland
2018-03-13 10:47       ` Mark Rutland
2018-03-13 11:07       ` AKASHI Takahiro
2018-03-13 11:07         ` AKASHI Takahiro
2018-03-13 11:20         ` Mark Rutland
2018-03-13 11:20           ` Mark Rutland
2018-03-13 19:48           ` Bhupesh Sharma
2018-03-13 19:48             ` Bhupesh Sharma
2018-03-14  2:10             ` AKASHI Takahiro
2018-03-14  2:10               ` AKASHI Takahiro
2018-03-14  5:03               ` Bhupesh Sharma
2018-03-14  5:03                 ` Bhupesh Sharma
2018-03-14  6:40                 ` AKASHI Takahiro
2018-03-14  6:40                   ` AKASHI Takahiro
2018-03-14 18:24               ` Mark Rutland
2018-03-14 18:24                 ` Mark Rutland
2018-03-16  9:35                 ` Bhupesh Sharma
2018-03-16  9:35                   ` Bhupesh Sharma
2018-04-06  2:09                   ` AKASHI Takahiro [this message]
2018-04-06  2:09                     ` AKASHI Takahiro
2018-04-09  4:01                     ` Bhupesh Sharma
2018-04-09  4:01                       ` Bhupesh Sharma
2018-04-09  4:31                       ` AKASHI Takahiro
2018-04-09  4:31                         ` AKASHI Takahiro
2018-04-09  9:28                         ` Ard Biesheuvel
2018-04-09  9:28                           ` Ard Biesheuvel
2018-04-09  9:39                           ` Baoquan He
2018-04-09  9:39                             ` Baoquan He
2018-04-09 18:28                           ` Bhupesh Sharma
2018-04-09 18:28                             ` Bhupesh Sharma
2018-04-10  0:47                             ` AKASHI Takahiro
2018-04-10  0:47                               ` AKASHI Takahiro
2018-04-14 20:14   ` Bhupesh Sharma
2018-04-14 20:14     ` Bhupesh Sharma
2018-04-18 11:52     ` Mark Rutland
2018-04-18 11:52       ` Mark Rutland
2018-04-23 20:34       ` Bhupesh Sharma
2018-04-23 20:34         ` Bhupesh Sharma

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=20180406020948.GE19607@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhsharma@redhat.com \
    --cc=bhupesh.linux@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    /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.