From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI Takahiro) Date: Tue, 10 Apr 2018 09:47:44 +0900 Subject: [Query] ARM64 kaslr support - randomness, seeding and kdump In-Reply-To: References: <20180313112016.ocx4qqhji3zfwjhs@lakrids.cambridge.arm.com> <20180314021050.GK25863@linaro.org> <20180314182448.bnvjtgyzipsuxcbe@lakrids.cambridge.arm.com> <20180406020948.GE19607@linaro.org> <20180409043138.GF19607@linaro.org> Message-ID: <20180410004742.GG19607@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Apr 09, 2018 at 11:58:21PM +0530, Bhupesh Sharma wrote: > Hi Ard, > > On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel > wrote: > > On 9 April 2018 at 06:31, AKASHI Takahiro 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 > >>> 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. > >> > >> 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? > > No, we are mainly considering here the 'kexec warm reboot to another > kernel' case and not the kdump case (although theoretically both the > cases are pretty similar). I meant so, too. -Takahiro AKASHI > So, I will use the terms primary and > secondary kernels below just theoretical clarity: > > 1. So let's consider the case where the arm64 primary kernel had > CONFIG_RANDOMIZE_BASE set to y and we have a compliant EFI firmware > which can support EFI_RNG_PROTOCOL and hence we have a non-zero > (valid) seed passed to the primary kernel. > > 2. Now the primary kernel reads the kaslr-seed and wipes it to 0 and > uses the value to randomize for e.g. the module base address. > > 3. In the case of kexec load (not kexec file load) or even kdump (for > brevity) , we rely on the user-space kexec-tools to pass an > appropriate dtb to the secondary kernel and since kaslr-seed is wiped > to 0 by the primary kernel, the secondary will work with *nokaslr* as > kaslr-seed is set to 0. > > 4. This can be true even in case the secondary kernel had > CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MODULE_REGION_FULL set to > y. > > 5. This behaviour probably needs fixing atleast for the kexec (as I > can think of no practical use-case for kdump) case. > > What are your views on the same? > > Regards, > Bhupesh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pf0-x22c.google.com ([2607:f8b0:400e:c00::22c]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f5hRs-0006Yr-Mg for kexec@lists.infradead.org; Tue, 10 Apr 2018 00:47:50 +0000 Received: by mail-pf0-x22c.google.com with SMTP id q9so6813368pff.1 for ; Mon, 09 Apr 2018 17:47:38 -0700 (PDT) Date: Tue, 10 Apr 2018 09:47:44 +0900 From: AKASHI Takahiro Subject: Re: [Query] ARM64 kaslr support - randomness, seeding and kdump Message-ID: <20180410004742.GG19607@linaro.org> References: <20180313112016.ocx4qqhji3zfwjhs@lakrids.cambridge.arm.com> <20180314021050.GK25863@linaro.org> <20180314182448.bnvjtgyzipsuxcbe@lakrids.cambridge.arm.com> <20180406020948.GE19607@linaro.org> <20180409043138.GF19607@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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: Bhupesh Sharma Cc: Mark Rutland , Bhupesh SHARMA , kexec@lists.infradead.org, linux-arm-kernel , Ard Biesheuvel On Mon, Apr 09, 2018 at 11:58:21PM +0530, Bhupesh Sharma wrote: > Hi Ard, > > On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel > wrote: > > On 9 April 2018 at 06:31, AKASHI Takahiro 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 > >>> 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. > >> > >> 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? > > No, we are mainly considering here the 'kexec warm reboot to another > kernel' case and not the kdump case (although theoretically both the > cases are pretty similar). I meant so, too. -Takahiro AKASHI > So, I will use the terms primary and > secondary kernels below just theoretical clarity: > > 1. So let's consider the case where the arm64 primary kernel had > CONFIG_RANDOMIZE_BASE set to y and we have a compliant EFI firmware > which can support EFI_RNG_PROTOCOL and hence we have a non-zero > (valid) seed passed to the primary kernel. > > 2. Now the primary kernel reads the kaslr-seed and wipes it to 0 and > uses the value to randomize for e.g. the module base address. > > 3. In the case of kexec load (not kexec file load) or even kdump (for > brevity) , we rely on the user-space kexec-tools to pass an > appropriate dtb to the secondary kernel and since kaslr-seed is wiped > to 0 by the primary kernel, the secondary will work with *nokaslr* as > kaslr-seed is set to 0. > > 4. This can be true even in case the secondary kernel had > CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MODULE_REGION_FULL set to > y. > > 5. This behaviour probably needs fixing atleast for the kexec (as I > can think of no practical use-case for kdump) case. > > What are your views on the same? > > Regards, > Bhupesh _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec