From mboxrd@z Thu Jan 1 00:00:00 1970 From: bhsharma@redhat.com (Bhupesh Sharma) Date: Mon, 9 Apr 2018 09:31:34 +0530 Subject: [Query] ARM64 kaslr support - randomness, seeding and kdump In-Reply-To: <20180406020948.GE19607@linaro.org> References: <20180313102158.GI25863@linaro.org> <20180313104715.prurmrizho4ddc4l@lakrids.cambridge.arm.com> <20180313110747.GJ25863@linaro.org> <20180313112016.ocx4qqhji3zfwjhs@lakrids.cambridge.arm.com> <20180314021050.GK25863@linaro.org> <20180314182448.bnvjtgyzipsuxcbe@lakrids.cambridge.arm.com> <20180406020948.GE19607@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Akashi, On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro 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 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. > 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? 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. Regards, Bhupesh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wm0-f65.google.com ([74.125.82.65]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f5O5i-0002fF-HZ for kexec@lists.infradead.org; Mon, 09 Apr 2018 04:07:40 +0000 Received: by mail-wm0-f65.google.com with SMTP id t67so15620678wmt.0 for ; Sun, 08 Apr 2018 21:07:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180406020948.GE19607@linaro.org> References: <20180313102158.GI25863@linaro.org> <20180313104715.prurmrizho4ddc4l@lakrids.cambridge.arm.com> <20180313110747.GJ25863@linaro.org> <20180313112016.ocx4qqhji3zfwjhs@lakrids.cambridge.arm.com> <20180314021050.GK25863@linaro.org> <20180314182448.bnvjtgyzipsuxcbe@lakrids.cambridge.arm.com> <20180406020948.GE19607@linaro.org> From: Bhupesh Sharma Date: Mon, 9 Apr 2018 09:31:34 +0530 Message-ID: Subject: Re: [Query] ARM64 kaslr support - randomness, seeding and kdump List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: AKASHI Takahiro , Bhupesh Sharma , Mark Rutland , Ard Biesheuvel , linux-arm-kernel , kexec@lists.infradead.org, Bhupesh SHARMA Hi Akashi, On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro 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 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. > 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? 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. Regards, Bhupesh _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec