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