linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [Query] ARM64 kaslr support - randomness, seeding and kdump
Date: Tue, 10 Apr 2018 09:47:44 +0900	[thread overview]
Message-ID: <20180410004742.GG19607@linaro.org> (raw)
In-Reply-To: <CACi5LpNAz41VZKkchkjc9SdxctK7Ui1zV_x=pyv0cEHFgfdHZQ@mail.gmail.com>

On Mon, Apr 09, 2018 at 11:58:21PM +0530, Bhupesh Sharma wrote:
> Hi Ard,
> 
> On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> > On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >> Hi,
> >>
> >> On Mon, Apr 09, 2018 at 09:31:34AM +0530, Bhupesh Sharma wrote:
> >>> Hi Akashi,
> >>>
> >>> On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro
> >>> <takahiro.akashi@linaro.org> wrote:
> >>> > 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 am almost done with the implementation.
> >>> Unfortunately I lost most of the last week trying to revive my arm64
> >>> board (which supports
> >>> EFI_RNG_PROTOCOL and hence can be used to test the kaslr-seed related
> >>> stuff), so I was not
> >>> able to test the implementation.
> >>>
> >>> Now that the board is up, I think I can test and thrash out any
> >>> missing clogs in the approach.
> >>
> >> Sounds good.
> >>
> >>> > I've already added kaslr support (i.e. "virtual randomisation") to
> >>> > my kexec_file patch set.
> >>> > # just a few lines of code, though
> >>>
> >>> Hmm, have you sent out a new version already (kexec_file_load), as the last
> >>> version in my inbox still mentions in the cover letter that we need a
> >>> EFI stub like approach
> >>> to really support CONFIG_RANDOMIZE_BASE. Or, am I missing something?
> >>
> >> No, not yet.
> >> While I've also added some sort of "physical randomisation",
> >> I'd like to put my post on hold until v4.17-rc1.
> >>
> >>> I would love to have a look at the patch and try it at my end, so
> >>> could you please share
> >>> a pointer to the same.
> >>
> >> Your test will be very much appreciated.
> >>
> >
> > Does this mean we have decided that we will enable KASLR in the kdump
> > kernel anyway, even if x86 disables it explicitly?
> 
> No, we are mainly considering here the 'kexec warm reboot to another
> kernel' case and not the kdump case (although theoretically both the
> cases are pretty similar).

I meant so, too.

-Takahiro AKASHI

> So, I will use the terms primary and
> secondary kernels below just theoretical clarity:
> 
> 1. So let's consider the case where the arm64 primary kernel had
> CONFIG_RANDOMIZE_BASE set to y and we have a compliant EFI firmware
> which can support EFI_RNG_PROTOCOL and hence we have a non-zero
> (valid) seed passed to the primary kernel.
> 
> 2. Now the primary kernel reads the kaslr-seed and wipes it to 0 and
> uses the value to randomize for e.g. the module base address.
> 
> 3. In the case of kexec load (not kexec file load) or even kdump (for
> brevity) , we rely on the user-space kexec-tools to pass an
> appropriate dtb to the secondary kernel and since kaslr-seed is wiped
> to 0 by the primary kernel, the secondary will work with *nokaslr* as
> kaslr-seed is set to 0.
> 
> 4. This can be true even in case the secondary kernel had
> CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MODULE_REGION_FULL set to
> y.
> 
> 5. This behaviour probably needs fixing atleast for the kexec (as I
> can think of no practical use-case for kdump) case.
> 
> What are your views on the same?
> 
> Regards,
> Bhupesh

  reply	other threads:[~2018-04-10  0:47 UTC|newest]

Thread overview: 23+ 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:58 ` Ard Biesheuvel
2018-03-13  1:54   ` Dave Young
2018-03-13 10:22   ` AKASHI Takahiro
2018-03-13 10:47     ` Mark Rutland
2018-03-13 11:07       ` AKASHI Takahiro
2018-03-13 11:20         ` Mark Rutland
2018-03-13 19:48           ` Bhupesh Sharma
2018-03-14  2:10             ` AKASHI Takahiro
2018-03-14  5:03               ` Bhupesh Sharma
2018-03-14  6:40                 ` AKASHI Takahiro
2018-03-14 18:24               ` Mark Rutland
2018-03-16  9:35                 ` Bhupesh Sharma
2018-04-06  2:09                   ` AKASHI Takahiro
2018-04-09  4:01                     ` Bhupesh Sharma
2018-04-09  4:31                       ` AKASHI Takahiro
2018-04-09  9:28                         ` Ard Biesheuvel
2018-04-09  9:39                           ` Baoquan He
2018-04-09 18:28                           ` Bhupesh Sharma
2018-04-10  0:47                             ` AKASHI Takahiro [this message]
2018-04-14 20:14   ` Bhupesh Sharma
2018-04-18 11:52     ` Mark Rutland
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=20180410004742.GG19607@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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).