[Query] ARM64 kaslr support - randomness, seeding and kdump

[Ard Biesheuvel]

On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi at 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 at 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 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 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?