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, 13 Mar 2018 20:07:49 +0900	[thread overview]
Message-ID: <20180313110747.GJ25863@linaro.org> (raw)
In-Reply-To: <20180313104715.prurmrizho4ddc4l@lakrids.cambridge.arm.com>

On Tue, Mar 13, 2018 at 10:47:15AM +0000, Mark Rutland wrote:
> On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> > On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote:
> > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> 
> > More importantly, neither arm64 _kexec_ supports kaslr.
> 
> The below is just considering this, and ignoring kdump (where I don't
> think we care at all about KASLR).
> 
> > Currently kexec-tools is set to determine where the kernel actually be
> > loaded, using a constant offset, text_offset, which comes from an image's
> > boot header and relocation of an image to the load address is performed
> > at the very end of the first kernel without knowing whether the 2nd kernel
> > has kaslr support enabled or not.
> 
> The kexec tools shouldn't need to know whether the kernel supports KASLR
> at all.
> 
> If the new kernel image has bit 3 (Kernel physical placement) set, kexec
> tools can choose to randomize the physical load address, regardless of
> whether that kernel has KASLR enabled.

So, by definition, is randomness, if we say so, in physical address not
part of KASLR?

> Note that the bootloader is responsible for physical randomization, and
> the kernel is responsible for virtual randomization. It just happens
> that the EFI stub acts as a bootloader when we use EFI.
> 
> > > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and
> > > > kexec list in this thread as well for their inputs), but currently we
> > > > don't seem to have a way to support kaslr in arm64 kdump kernel:
> > > >
> > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel
> > 
> > So, even if adding /chosen/kaslr-seed to dtb at kexec would not be
> > difficult, we would have to have efi_entry-like entry code.
> 
> The kaslr-seed property is used for *virtual* randomization, so we don't
> need more code in the kernel for this. The kexec tools can populate this
> property if desired.

Hmm, so saving/re-using kaslr-seed of the 1st kernel, as Bhupesh hinted,
is not important, anyway.

-Takahiro AKASHI


> Thanks,
> Mark.

  reply	other threads:[~2018-03-13 11:07 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 [this message]
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
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=20180313110747.GJ25863@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).