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. Thanks, -Takahiro AKASHI > > Regards, > Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
