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.
next prev parent 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).