On 04/09/18 at 11:28am, Ard Biesheuvel wrote: > On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxx> 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? x86 doesn't disable kaslr in kernel, we did it in clue scripts. Since kdump kernel is not different than normal kernel. But it truly makes no any sense to enable kaslr in kdump kernel. > _______________________________________________ > kexec mailing list > kexec@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
