Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
Hi Mark,
On Wed, Apr 18, 2018 at 5:22 PM, Mark Rutland wrote:
> On Sun, Apr 15, 2018 at 01:44:16AM +0530, Bhupesh Sharma wrote:
>> 4. Accordingly, I wanted to get opinions on whether arm64 timer count is a
>> good
>> entropy source on platforms which indeed support EFI_RNG_PROTOCOL?
>
> On its own, the timer is not a good entropy source.
>
> If we have the EFI_RNG_PROTOCOL, we can use that directly.
>
>> And whether we should be looking to extend 'arch_get_random_*' or
>> 'random_get_entropy' for arm64, to provide seed/entropy using APIs
>> like 'efi_random_get_seed'?
>
> The EFI RNG protocol is only available during boot services, so we can't
> call this during the usual operation of the kernel. The seed the stub
> generates into the RNG table is already thrown into the entropy pool by
> efi_config_parse_tables(). Look for LINUX_EFI_RANDOM_SEED_TABLE_GUID.
>
> So any attemps to acquire a random number via the usual APIs will in
> part be affects by this entropy, and nothing needs to be done to
> arch_get_random_* to use this entropy.
Sorry for the late reply, it took me some time to have a relook at the
code on the basis of your inputs.
Actually I remember discussing this with a few folks some time back in
one of the UEFI forum events, but its still not very clear to me why
the UEFI specifications would not have the EFI RNG protocol as a
runtime service and only as a boot-time service.
I believe that getting the RNG number directly from the firmware (via
a runtime service call) is probably better than relying on OS RNG
sources like '/dev/random' and '/dev/urandom' which may have known
limitations (which have been discussed time and again on several
upstream threads on lkml).
Also if the EFI RNG protocol is implemented as a runtime protocol in
the UEFI specifications, perhaps we can use 'get_random_bytes_arch()'
like APIs from the kernel to generate arch specific random numbers
faster as compared to relying on the 'chacha20' like interfaces.
Also, I now understand that with the early efi stub boot the following
function call sequence adds initial/boot time randomness to the
'/dev/urandom' pool, so thanks for sharing the pointers for the same:
efi_config_parse_tables ()
-> add_device_randomness ()
-> if (!crng_ready()) {
crng_fast_load(buf, size);
Regards,
Bhupesh
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Sun, Apr 15, 2018 at 01:44:16AM +0530, Bhupesh Sharma wrote: > 4. Accordingly, I wanted to get opinions on whether arm64 timer count is a > good > entropy source on platforms which indeed support EFI_RNG_PROTOCOL? On its own, the timer is not a good entropy source. If we have the EFI_RNG_PROTOCOL, we can use that directly. > And whether we should be looking to extend 'arch_get_random_*' or > 'random_get_entropy' for arm64, to provide seed/entropy using APIs > like 'efi_random_get_seed'? The EFI RNG protocol is only available during boot services, so we can't call this during the usual operation of the kernel. The seed the stub generates into the RNG table is already thrown into the entropy pool by efi_config_parse_tables(). Look for LINUX_EFI_RANDOM_SEED_TABLE_GUID. So any attemps to acquire a random number via the usual APIs will in part be affects by this entropy, and nothing needs to be done to arch_get_random_* to use this entropy. Thanks, Mark. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
Hi Ard,
On Tue, Mar 13, 2018 at 2:28 AM, Ard Biesheuvel
wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma wrote:
>> Hi Ard,
>>
>> I remember we had a discussion on this topic some time ago, but I was
>> working on enabling KASLR support on arm64 boards internally and
>> wanted to check your opinion on the following points (especially to
>> understand if there are any changes in the opinions of the ARM
>> maintainers now):
>>
>> A. Randomness / Seeding for arm64 kaslr:
>>
>> - Currently the arm64 kernel requires a bootloader to provide entropy,
>> by passing a
>> random u64 value in '/chosen/kaslr-seed' at kernel entry (please see [1])
>>
>> - On platforms which support UEFI firmware, its the responsibility of
>> the UEFI firmware to implement EFI_RNG_PROTOCOL to supply the
>> '/chosen/kaslr-seed' property.
>>
>> - I was wondering if we have any possibility to support a random seed
>> generation like the x86 in the efistub only rather than relying on the
>> UEFI firmwares with EFI_RNG_PROTOCOL for the same - for e.g. by using
>> a randomness seed like the boot time or more proper entropy sources
>> like arm64 system timer (see [2] for x86 example).
>>
>> - I guess that the main problem is that most arm64 UEFI firmware
>> vendors still do not support EFI_RNG_PROTOCOL out of the box. We can
>> use the ChaosKey (see [3]) EFI driver and use this USB key as the
>> source of entropy on the arm64 systems for EFI firmwares which do not
>> provide a EFI_RNG_PROTOCOL implementation, but it might not be very
>> feasible to connect it to all boards in a production environment.
>>
>
> The problem is that arm64 does not have an architected means of
> obtaining entropy, and we shouldn't rely on hacks to get pseudo
> entropy.
>
> Note that EFI_RNG_PROTOCOL is not only used for KASLR, it is also used
> to seed the kernel entropy pool if the firmware provides an
> implementation of the protocol.
Coming back on this, I was doing some experimentation with kernel
modules (or extending the argument even
to user-space applications) which relies on random number generation support
from the kernel using 'getrandom' / 'get_random_bytes' kind of
syscall/kernel interface, on platforms where we don't have a
compatible EFI firmware which supports EFI_RNG_PROTOCOL, I was
thinking that there
would not be sufficient entropy (inside '/dev/urandom') available for
the caller kernel modules (or user-space applications)
and I was looking to enable 'CONFIG_WARN_ALL_UNSEEDED_RANDOM=y' to ensure that
callers of unseeded randomness in such kernel modules/user-space
applications are WARN'ed.
1. Instead I saw that random numbers are available on these platforms
starting from early boot (i.e. crng init is already done):
[root@qualcomm-amberwing]# dmesg | grep -i random
random: crng init done
2. The reason is that upstream aarch64 kernel uses the timer counter
value to generate random numbers starting from early boot (which is
probable not a good alternative when we have a compatible EFI firmware
which can pass entropy to the kernel):
'include/linux/timex.h' :
---
#define random_get_entropy()get_cycles()
'arch/arm64/include/asm/timex.h' :
---
/*
* Use the current timer as a cycle counter since this is what we use for
* the delay loop.
*/
#define get_cycles()arch_timer_read_counter()
'drivers/clocksource/arm_arch_timer.c' :
--
u64 (*arch_timer_read_counter)(void) = arch_counter_get_cntvct;
3. And when other linux kernel modules (or even userspace
applications) try to do some random number generation using the kernel
support using 'getrandom' / 'get_random_bytes', the entropy is already
available.
So the caller would be supplied with random numbers, as I confirmed on
arm64 platforms which do not support EFI_RNG_PROTOCOL:
Also on such platforms 'wait_for_random_bytes' returns 0 indicating
that the 'urandom' pool has been seeded:
/*
* Wait for the urandom pool to be seeded and thus guaranteed to supply
* cryptographically secure random numbers. This applies to: the /dev/urandom
* device, the get_random_bytes function, and the get_random_{u32,u64,int,long}
* family of functions. Using any of these functions without first calling
* this function forfeits the guarantee of security.
*
* Returns: 0 if the urandom pool has been seeded.
* -ERESTARTSYS if the function was interrupted by a signal.
*/
int wait_for_random_bytes(void)
4. Accordingly, I wanted to get opinions on whether arm64 timer count is a good
entropy source on platforms which indeed support EFI_RNG_PROTOCOL? And
whether we should be looking to extend 'arch_get_random_*' or
'random_get_entropy' for arm64, to provide seed/entropy using APIs
like 'efi_random_get_seed'?
If this seems feasible I can try to take a stab at the same.
Please share your views.
Thanks,
Bhupesh
___
kexec mailing list
ke
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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). 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
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On 04/09/18 at 11:28am, 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? 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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. Thanks, -Takahiro AKASHI > > Regards, > Bhupesh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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've already added kaslr support (i.e. "virtual randomisation") to my kexec_file patch set. # just a few lines of code, though -Takahiro AKASHI > Thanks, > Bhupesh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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. Thanks, Bhupesh ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
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. Thanks, Mark. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Wed, Mar 14, 2018 at 10:33:03AM +0530, Bhupesh Sharma wrote: > ' > > On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro > wrote: > > On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote: > >> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland wrote: > >> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote: > >> >> On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote: > >> >> > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: > >> >> > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: > >> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma > >> >> > > > wrote: > >> >> > > >> >> > > More importantly, neither arm64 _kexec_ supports kaslr. > >> > >> Sorry if my earlier email was not clear on this, but I meant both the > >> kdump/kexec cases. > >> > >> While for kdump there is no current requirement for physical > >> randomization, for kexec it would be good to support the same as the > >> primary kernel was already supporting kaslr and the secondary kernel > >> (if compiled with CONFIG_RANDOMIZE_BASE) would randomizes the virtual > >> address at which the kernel image is loaded. > >> > >> If we have physical randomization supported in this case in the > >> secondary/kexec kernel we can avoid potential misuse related to the > >> physical address being known at which the secondary/kexec kernel is > >> loaded. > >> > >> >> > > >> >> > The below is just considering this, and ignoring kdump (where I don't > >> >> > think we care at all about KASLR). > >> >> > > >> >> > > Currently kexec-tools is set to determine where the kernel actually > >> >> > > be > >> >> > > loaded, using a constant offset, text_offset, which comes from an > >> >> > > image's > >> >> > > boot header and relocation of an image to the load address is > >> >> > > performed > >> >> > > at the very end of the first kernel without knowing whether the 2nd > >> >> > > kernel > >> >> > > has kaslr support enabled or not. > >> >> > > >> >> > The kexec tools shouldn't need to know whether the kernel supports > >> >> > KASLR > >> >> > at all. > >> >> > > >> >> > If the new kernel image has bit 3 (Kernel physical placement) set, > >> >> > kexec > >> >> > tools can choose to randomize the physical load address, regardless of > >> >> > whether that kernel has KASLR enabled. > >> >> > >> >> So, by definition, is randomness, if we say so, in physical address not > >> >> part of KASLR? > >> > > >> > Physical randomization is not part of the kernel's KASLR implementation. > >> > > >> > We happen to do it in the EFI stub, because we can in that context. But > >> > generally, physical randomization is not part of arm64's in-kernel > >> > KASLR. > >> > > >> > For various reasons, the physical address that the kernel is loaded to > >> > may be arbitrary, so we have to cope with physical randomization > >> > regardless. > >> > >> Indeed, since the primary kernel depends on the firmware's > >> EFI_RNG_PROTOCOL implementation (if available) to randomise the > >> physical location of the kernel Image, for the secondary/kexec kernel, > >> if can have two approaches to enable physical randomization: > > > > I believe that you're now talking about "virtual" randomization. > > > >> - Implement a UEFI stub for loading the kexec kernel as well, or > >> > >> - Extend the 'kexec-tools' to invoke the entropy source available in > >> the primary kernel (provided by the firmware via EFI_RNG_PROTOCOL) to > >> generate a random seed to randomize the physical address and populate > >> it in the '/chosen/kaslr-seed' property of the device-tree being > >> passed to the secondary/kexec kernel and let the normal code flow in > >> ' arch/arm64/kernel/kaslr.c', function 'kaslr_early_init' to get the > >> seed for the secondary kernel from the '/chosen/kaslr-seed' property > >> itself. > >> > >> Personally the later approach looks simpler to me from a implementation > >> p-o-v. > > > > 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. > > But doesn't this problem exist in the arm64 kexec design already for > kexec_load() case? > Since it relies on sending a dtb (updated with the > 'linux,usable-memory') property to the secondary/kexec kernel, we can > easily introduce a security vulnerability in the system by expanding > the dtb to include a static value for '/chosen/kaslr-seed'. > > Consider the following scenario (which I tried yesterday on my arm64 > board just out of curiosity): > > 1. Primary kernel and secondary kernel both are compiled with kaslr > flags (CONFIG_RANDOMIZE_BASE) > > 2. Primary kernel is loaded at random physical address on the basis of > the '/chosen/kaslr-seed' property. > > 3. Thereafter this property is memset to 0. > > 4. Now we call 'kexec -l + kexec -e' combination to warm boot to a > secondary/kexec kernel. > > 5. Since 'kexec-tools' picks up the existing dtb with > '/chose
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
' On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro wrote: > On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote: >> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland wrote: >> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote: >> >> On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote: >> >> > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: >> >> > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: >> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma >> >> > > > wrote: >> >> > >> >> > > More importantly, neither arm64 _kexec_ supports kaslr. >> >> Sorry if my earlier email was not clear on this, but I meant both the >> kdump/kexec cases. >> >> While for kdump there is no current requirement for physical >> randomization, for kexec it would be good to support the same as the >> primary kernel was already supporting kaslr and the secondary kernel >> (if compiled with CONFIG_RANDOMIZE_BASE) would randomizes the virtual >> address at which the kernel image is loaded. >> >> If we have physical randomization supported in this case in the >> secondary/kexec kernel we can avoid potential misuse related to the >> physical address being known at which the secondary/kexec kernel is >> loaded. >> >> >> > >> >> > The below is just considering this, and ignoring kdump (where I don't >> >> > think we care at all about KASLR). >> >> > >> >> > > Currently kexec-tools is set to determine where the kernel actually be >> >> > > loaded, using a constant offset, text_offset, which comes from an >> >> > > image's >> >> > > boot header and relocation of an image to the load address is >> >> > > performed >> >> > > at the very end of the first kernel without knowing whether the 2nd >> >> > > kernel >> >> > > has kaslr support enabled or not. >> >> > >> >> > The kexec tools shouldn't need to know whether the kernel supports KASLR >> >> > at all. >> >> > >> >> > If the new kernel image has bit 3 (Kernel physical placement) set, kexec >> >> > tools can choose to randomize the physical load address, regardless of >> >> > whether that kernel has KASLR enabled. >> >> >> >> So, by definition, is randomness, if we say so, in physical address not >> >> part of KASLR? >> > >> > Physical randomization is not part of the kernel's KASLR implementation. >> > >> > We happen to do it in the EFI stub, because we can in that context. But >> > generally, physical randomization is not part of arm64's in-kernel >> > KASLR. >> > >> > For various reasons, the physical address that the kernel is loaded to >> > may be arbitrary, so we have to cope with physical randomization >> > regardless. >> >> Indeed, since the primary kernel depends on the firmware's >> EFI_RNG_PROTOCOL implementation (if available) to randomise the >> physical location of the kernel Image, for the secondary/kexec kernel, >> if can have two approaches to enable physical randomization: > > I believe that you're now talking about "virtual" randomization. > >> - Implement a UEFI stub for loading the kexec kernel as well, or >> >> - Extend the 'kexec-tools' to invoke the entropy source available in >> the primary kernel (provided by the firmware via EFI_RNG_PROTOCOL) to >> generate a random seed to randomize the physical address and populate >> it in the '/chosen/kaslr-seed' property of the device-tree being >> passed to the secondary/kexec kernel and let the normal code flow in >> ' arch/arm64/kernel/kaslr.c', function 'kaslr_early_init' to get the >> seed for the secondary kernel from the '/chosen/kaslr-seed' property >> itself. >> >> Personally the later approach looks simpler to me from a implementation >> p-o-v. > > 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. But doesn't this problem exist in the arm64 kexec design already for kexec_load() case? Since it relies on sending a dtb (updated with the 'linux,usable-memory') property to the secondary/kexec kernel, we can easily introduce a security vulnerability in the system by expanding the dtb to include a static value for '/chosen/kaslr-seed'. Consider the following scenario (which I tried yesterday on my arm64 board just out of curiosity): 1. Primary kernel and secondary kernel both are compiled with kaslr flags (CONFIG_RANDOMIZE_BASE) 2. Primary kernel is loaded at random physical address on the basis of the '/chosen/kaslr-seed' property. 3. Thereafter this property is memset to 0. 4. Now we call 'kexec -l + kexec -e' combination to warm boot to a secondary/kexec kernel. 5. Since 'kexec-tools' picks up the existing dtb with '/chosen/kaslr-seed' set to 0, it passes the same to the secondary/kexec kernel. 6. Instead if we have a vulnerable 'kexec-tools' user space application, which unpacks the dtb and sets the '/chosen/kaslr-seed' to a known static non-zero value. 7. Now the secondary/kexec kernel is invoked and the 'kaslr_early_init()' finds a v
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote:
> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland wrote:
> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> >> On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote:
> >> > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> >> > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote:
> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma
> >> > > > wrote:
> >> >
> >> > > More importantly, neither arm64 _kexec_ supports kaslr.
>
> Sorry if my earlier email was not clear on this, but I meant both the
> kdump/kexec cases.
>
> While for kdump there is no current requirement for physical
> randomization, for kexec it would be good to support the same as the
> primary kernel was already supporting kaslr and the secondary kernel
> (if compiled with CONFIG_RANDOMIZE_BASE) would randomizes the virtual
> address at which the kernel image is loaded.
>
> If we have physical randomization supported in this case in the
> secondary/kexec kernel we can avoid potential misuse related to the
> physical address being known at which the secondary/kexec kernel is
> loaded.
>
> >> >
> >> > The below is just considering this, and ignoring kdump (where I don't
> >> > think we care at all about KASLR).
> >> >
> >> > > Currently kexec-tools is set to determine where the kernel actually be
> >> > > loaded, using a constant offset, text_offset, which comes from an
> >> > > image's
> >> > > boot header and relocation of an image to the load address is performed
> >> > > at the very end of the first kernel without knowing whether the 2nd
> >> > > kernel
> >> > > has kaslr support enabled or not.
> >> >
> >> > The kexec tools shouldn't need to know whether the kernel supports KASLR
> >> > at all.
> >> >
> >> > If the new kernel image has bit 3 (Kernel physical placement) set, kexec
> >> > tools can choose to randomize the physical load address, regardless of
> >> > whether that kernel has KASLR enabled.
> >>
> >> So, by definition, is randomness, if we say so, in physical address not
> >> part of KASLR?
> >
> > Physical randomization is not part of the kernel's KASLR implementation.
> >
> > We happen to do it in the EFI stub, because we can in that context. But
> > generally, physical randomization is not part of arm64's in-kernel
> > KASLR.
> >
> > For various reasons, the physical address that the kernel is loaded to
> > may be arbitrary, so we have to cope with physical randomization
> > regardless.
>
> Indeed, since the primary kernel depends on the firmware's
> EFI_RNG_PROTOCOL implementation (if available) to randomise the
> physical location of the kernel Image, for the secondary/kexec kernel,
> if can have two approaches to enable physical randomization:
I believe that you're now talking about "virtual" randomization.
> - Implement a UEFI stub for loading the kexec kernel as well, or
>
> - Extend the 'kexec-tools' to invoke the entropy source available in
> the primary kernel (provided by the firmware via EFI_RNG_PROTOCOL) to
> generate a random seed to randomize the physical address and populate
> it in the '/chosen/kaslr-seed' property of the device-tree being
> passed to the secondary/kexec kernel and let the normal code flow in
> ' arch/arm64/kernel/kaslr.c', function 'kaslr_early_init' to get the
> seed for the secondary kernel from the '/chosen/kaslr-seed' property
> itself.
>
> Personally the later approach looks simpler to me from a implementation p-o-v.
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.
(Speaking of kexec_file, we can easily adopt this approach as fdt modification
is done totally inside the kernel. Likewise, "physical" randomization would be
easy in part of arm64_relocate_new_kernel() because we only have to care bit 3
of boot header's flags after Mark's comment.)
-Takahiro AKASHI
> For example, currently in the kernel we normally invoke 'update_fdt'
> (inside 'drivers/fimrware/efi/libstub/fdt.c') from the UEFI stub,
> wherein we have this check for CONFIG_RANDOMIZE_BASE:
>
> static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>unsigned long orig_fdt_size,
>void *fdt, int new_fdt_size, char *cmdline_ptr,
>u64 initrd_addr, u64 initrd_size)
> {
>
> ...
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> efi_status_t efi_status;
>
> efi_status = efi_get_random_bytes(sys_table, sizeof(fdt_val64),
> (u8 *)&fdt_val64);
> if (efi_status == EFI_SUCCESS) {
> status = fdt_setprop(fdt, node, "kaslr-seed",
> &fdt_val64, sizeof(fdt_val64));
> if (status)
> goto fdt_set_fail;
> } else if (efi_status != EFI_NOT_FOUND) {
> return efi_status;
> }
> }
> ...
> }
>
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland wrote:
> On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote:
>> > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
>> > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote:
>> > > > On 12 March 2018 at 20:14, Bhupesh Sharma wrote:
>> >
>> > > More importantly, neither arm64 _kexec_ supports kaslr.
Sorry if my earlier email was not clear on this, but I meant both the
kdump/kexec cases.
While for kdump there is no current requirement for physical
randomization, for kexec it would be good to support the same as the
primary kernel was already supporting kaslr and the secondary kernel
(if compiled with CONFIG_RANDOMIZE_BASE) would randomizes the virtual
address at which the kernel image is loaded.
If we have physical randomization supported in this case in the
secondary/kexec kernel we can avoid potential misuse related to the
physical address being known at which the secondary/kexec kernel is
loaded.
>> >
>> > The below is just considering this, and ignoring kdump (where I don't
>> > think we care at all about KASLR).
>> >
>> > > Currently kexec-tools is set to determine where the kernel actually be
>> > > loaded, using a constant offset, text_offset, which comes from an image's
>> > > boot header and relocation of an image to the load address is performed
>> > > at the very end of the first kernel without knowing whether the 2nd
>> > > kernel
>> > > has kaslr support enabled or not.
>> >
>> > The kexec tools shouldn't need to know whether the kernel supports KASLR
>> > at all.
>> >
>> > If the new kernel image has bit 3 (Kernel physical placement) set, kexec
>> > tools can choose to randomize the physical load address, regardless of
>> > whether that kernel has KASLR enabled.
>>
>> So, by definition, is randomness, if we say so, in physical address not
>> part of KASLR?
>
> Physical randomization is not part of the kernel's KASLR implementation.
>
> We happen to do it in the EFI stub, because we can in that context. But
> generally, physical randomization is not part of arm64's in-kernel
> KASLR.
>
> For various reasons, the physical address that the kernel is loaded to
> may be arbitrary, so we have to cope with physical randomization
> regardless.
Indeed, since the primary kernel depends on the firmware's
EFI_RNG_PROTOCOL implementation (if available) to randomise the
physical location of the kernel Image, for the secondary/kexec kernel,
if can have two approaches to enable physical randomization:
- Implement a UEFI stub for loading the kexec kernel as well, or
- Extend the 'kexec-tools' to invoke the entropy source available in
the primary kernel (provided by the firmware via EFI_RNG_PROTOCOL) to
generate a random seed to randomize the physical address and populate
it in the '/chosen/kaslr-seed' property of the device-tree being
passed to the secondary/kexec kernel and let the normal code flow in
' arch/arm64/kernel/kaslr.c', function 'kaslr_early_init' to get the
seed for the secondary kernel from the '/chosen/kaslr-seed' property
itself.
Personally the later approach looks simpler to me from a implementation p-o-v.
For example, currently in the kernel we normally invoke 'update_fdt'
(inside 'drivers/fimrware/efi/libstub/fdt.c') from the UEFI stub,
wherein we have this check for CONFIG_RANDOMIZE_BASE:
static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long orig_fdt_size,
void *fdt, int new_fdt_size, char *cmdline_ptr,
u64 initrd_addr, u64 initrd_size)
{
...
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
efi_status_t efi_status;
efi_status = efi_get_random_bytes(sys_table, sizeof(fdt_val64),
(u8 *)&fdt_val64);
if (efi_status == EFI_SUCCESS) {
status = fdt_setprop(fdt, node, "kaslr-seed",
&fdt_val64, sizeof(fdt_val64));
if (status)
goto fdt_set_fail;
} else if (efi_status != EFI_NOT_FOUND) {
return efi_status;
}
}
...
}
I am thinking of modifying the kexec-tools code for arm64 (which
already processes the device tree to pass it to the secondary/kexec
kernel), so that we can do something like the following:
--> efi_get_random_bytes(sys_table, sizeof(fdt_val64),
(u8 *)&fdt_val64);
--> fdt_setprop(fdt, node, "kaslr-seed", &fdt_val64,
sizeof(fdt_val64));
Now when the modified dtb is passed to the secondary/kexec kernel it
will automatically find a valid seed, will wipe it to zero for
security reasons and use the same to perform physical randomization.
If this looks sensible I will try to take a stab at this approach and
share results on thread in the coming days.
Please share your inputs.
Regards,
Bhupesh
___
kexec m
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote: > On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote: > > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: > > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: > > > > On 12 March 2018 at 20:14, Bhupesh Sharma wrote: > > > > > More importantly, neither arm64 _kexec_ supports kaslr. > > > > The below is just considering this, and ignoring kdump (where I don't > > think we care at all about KASLR). > > > > > Currently kexec-tools is set to determine where the kernel actually be > > > loaded, using a constant offset, text_offset, which comes from an image's > > > boot header and relocation of an image to the load address is performed > > > at the very end of the first kernel without knowing whether the 2nd kernel > > > has kaslr support enabled or not. > > > > The kexec tools shouldn't need to know whether the kernel supports KASLR > > at all. > > > > If the new kernel image has bit 3 (Kernel physical placement) set, kexec > > tools can choose to randomize the physical load address, regardless of > > whether that kernel has KASLR enabled. > > So, by definition, is randomness, if we say so, in physical address not > part of KASLR? Physical randomization is not part of the kernel's KASLR implementation. We happen to do it in the EFI stub, because we can in that context. But generally, physical randomization is not part of arm64's in-kernel KASLR. For various reasons, the physical address that the kernel is loaded to may be arbitrary, so we have to cope with physical randomization regardless. Thanks, Mark. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Tue, Mar 13, 2018 at 10:47:15AM +, Mark Rutland wrote: > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: > > > On 12 March 2018 at 20:14, Bhupesh Sharma wrote: > > > More importantly, neither arm64 _kexec_ supports kaslr. > > The below is just considering this, and ignoring kdump (where I don't > think we care at all about KASLR). > > > Currently kexec-tools is set to determine where the kernel actually be > > loaded, using a constant offset, text_offset, which comes from an image's > > boot header and relocation of an image to the load address is performed > > at the very end of the first kernel without knowing whether the 2nd kernel > > has kaslr support enabled or not. > > The kexec tools shouldn't need to know whether the kernel supports KASLR > at all. > > If the new kernel image has bit 3 (Kernel physical placement) set, kexec > tools can choose to randomize the physical load address, regardless of > whether that kernel has KASLR enabled. So, by definition, is randomness, if we say so, in physical address not part of KASLR? > Note that the bootloader is responsible for physical randomization, and > the kernel is responsible for virtual randomization. It just happens > that the EFI stub acts as a bootloader when we use EFI. > > > > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > > > > kexec list in this thread as well for their inputs), but currently we > > > > don't seem to have a way to support kaslr in arm64 kdump kernel: > > > > > > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel > > > > So, even if adding /chosen/kaslr-seed to dtb at kexec would not be > > difficult, we would have to have efi_entry-like entry code. > > The kaslr-seed property is used for *virtual* randomization, so we don't > need more code in the kernel for this. The kexec tools can populate this > property if desired. Hmm, so saving/re-using kaslr-seed of the 1st kernel, as Bhupesh hinted, is not important, anyway. -Takahiro AKASHI > Thanks, > Mark. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote: > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: > > On 12 March 2018 at 20:14, Bhupesh Sharma wrote: > More importantly, neither arm64 _kexec_ supports kaslr. The below is just considering this, and ignoring kdump (where I don't think we care at all about KASLR). > Currently kexec-tools is set to determine where the kernel actually be > loaded, using a constant offset, text_offset, which comes from an image's > boot header and relocation of an image to the load address is performed > at the very end of the first kernel without knowing whether the 2nd kernel > has kaslr support enabled or not. The kexec tools shouldn't need to know whether the kernel supports KASLR at all. If the new kernel image has bit 3 (Kernel physical placement) set, kexec tools can choose to randomize the physical load address, regardless of whether that kernel has KASLR enabled. Note that the bootloader is responsible for physical randomization, and the kernel is responsible for virtual randomization. It just happens that the EFI stub acts as a bootloader when we use EFI. > > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > > > kexec list in this thread as well for their inputs), but currently we > > > don't seem to have a way to support kaslr in arm64 kdump kernel: > > > > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel > > So, even if adding /chosen/kaslr-seed to dtb at kexec would not be > difficult, we would have to have efi_entry-like entry code. The kaslr-seed property is used for *virtual* randomization, so we don't need more code in the kernel for this. The kexec tools can populate this property if desired. Thanks, Mark. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote: > On 12 March 2018 at 20:14, Bhupesh Sharma wrote: > > Hi Ard, > > > > I remember we had a discussion on this topic some time ago, but I was > > working on enabling KASLR support on arm64 boards internally and > > wanted to check your opinion on the following points (especially to > > understand if there are any changes in the opinions of the ARM > > maintainers now): > > > > A. Randomness / Seeding for arm64 kaslr: > > > > - Currently the arm64 kernel requires a bootloader to provide entropy, > > by passing a > > random u64 value in '/chosen/kaslr-seed' at kernel entry (please see [1]) > > > > - On platforms which support UEFI firmware, its the responsibility of > > the UEFI firmware to implement EFI_RNG_PROTOCOL to supply the > > '/chosen/kaslr-seed' property. > > > > - I was wondering if we have any possibility to support a random seed > > generation like the x86 in the efistub only rather than relying on the > > UEFI firmwares with EFI_RNG_PROTOCOL for the same - for e.g. by using > > a randomness seed like the boot time or more proper entropy sources > > like arm64 system timer (see [2] for x86 example). > > > > - I guess that the main problem is that most arm64 UEFI firmware > > vendors still do not support EFI_RNG_PROTOCOL out of the box. We can > > use the ChaosKey (see [3]) EFI driver and use this USB key as the > > source of entropy on the arm64 systems for EFI firmwares which do not > > provide a EFI_RNG_PROTOCOL implementation, but it might not be very > > feasible to connect it to all boards in a production environment. > > > > The problem is that arm64 does not have an architected means of > obtaining entropy, and we shouldn't rely on hacks to get pseudo > entropy. > > Note that EFI_RNG_PROTOCOL is not only used for KASLR, it is also used > to seed the kernel entropy pool if the firmware provides an > implementation of the protocol. > > Any UEFI system that can boot off USB should be able to use the > ChaosKey as well, but the best approach is obviously to implement > EFI_RNG_PROTOCOL natively if the platform has an entropy source > available. > > If a platform vendor wants to hack something up based on the timer or > the performance counter, they are free to do so. But that doesn't mean > we should implement anything along those lines in the kernel. > > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > > kexec list in this thread as well for their inputs), but currently we > > don't seem to have a way to support kaslr in arm64 kdump kernel: > > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel > > (to avoid leaking out randomness secret), but how should this be then > > handed over to the kdump kernel. > > - We pass the dtb over to the kdump kernel for arm64 kdump, but the > > '/chosen/kaslr-seed' property would be zeroed out already by the > > primary kernel and the secondary would work in a *nokaslr* environment > > due to the same (see [4] for example) > > > > What would be the point of randomizing the placement of the kdump > kernel? And don't say 'because x86 does it', because that is not a > good reason. More importantly, neither arm64 _kexec_ supports kaslr. Currently kexec-tools is set to determine where the kernel actually be loaded, using a constant offset, text_offset, which comes from an image's boot header and relocation of an image to the load address is performed at the very end of the first kernel without knowing whether the 2nd kernel has kaslr support enabled or not. > > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > > kexec list in this thread as well for their inputs), but currently we > > don't seem to have a way to support kaslr in arm64 kdump kernel: > > > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel So, even if adding /chosen/kaslr-seed to dtb at kexec would not be difficult, we would have to have efi_entry-like entry code. Thanks, -Takahiro AKASHI ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On 03/12/18 at 08:58pm, Ard Biesheuvel wrote: [snip] > > - We pass the dtb over to the kdump kernel for arm64 kdump, but the > > '/chosen/kaslr-seed' property would be zeroed out already by the > > primary kernel and the secondary would work in a *nokaslr* environment > > due to the same (see [4] for example) > > > > What would be the point of randomizing the placement of the kdump > kernel? And don't say 'because x86 does it', because that is not a > good reason. Kdump kernel does not need kaslr. Actually in Fedora we use 'nokaslr' even for x86_64 Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Query] ARM64 kaslr support - randomness, seeding and kdump
On 12 March 2018 at 20:14, Bhupesh Sharma wrote: > Hi Ard, > > I remember we had a discussion on this topic some time ago, but I was > working on enabling KASLR support on arm64 boards internally and > wanted to check your opinion on the following points (especially to > understand if there are any changes in the opinions of the ARM > maintainers now): > > A. Randomness / Seeding for arm64 kaslr: > > - Currently the arm64 kernel requires a bootloader to provide entropy, > by passing a > random u64 value in '/chosen/kaslr-seed' at kernel entry (please see [1]) > > - On platforms which support UEFI firmware, its the responsibility of > the UEFI firmware to implement EFI_RNG_PROTOCOL to supply the > '/chosen/kaslr-seed' property. > > - I was wondering if we have any possibility to support a random seed > generation like the x86 in the efistub only rather than relying on the > UEFI firmwares with EFI_RNG_PROTOCOL for the same - for e.g. by using > a randomness seed like the boot time or more proper entropy sources > like arm64 system timer (see [2] for x86 example). > > - I guess that the main problem is that most arm64 UEFI firmware > vendors still do not support EFI_RNG_PROTOCOL out of the box. We can > use the ChaosKey (see [3]) EFI driver and use this USB key as the > source of entropy on the arm64 systems for EFI firmwares which do not > provide a EFI_RNG_PROTOCOL implementation, but it might not be very > feasible to connect it to all boards in a production environment. > The problem is that arm64 does not have an architected means of obtaining entropy, and we shouldn't rely on hacks to get pseudo entropy. Note that EFI_RNG_PROTOCOL is not only used for KASLR, it is also used to seed the kernel entropy pool if the firmware provides an implementation of the protocol. Any UEFI system that can boot off USB should be able to use the ChaosKey as well, but the best approach is obviously to implement EFI_RNG_PROTOCOL natively if the platform has an entropy source available. If a platform vendor wants to hack something up based on the timer or the performance counter, they are free to do so. But that doesn't mean we should implement anything along those lines in the kernel. > B. Regarding the arm64 kaslr support in kdump (I have Cc'ed AKASHI and > kexec list in this thread as well for their inputs), but currently we > don't seem to have a way to support kaslr in arm64 kdump kernel: > > - '/chosen/kaslr-seed' a property is zeroed out in the primary kernel > (to avoid leaking out randomness secret), but how should this be then > handed over to the kdump kernel. > - We pass the dtb over to the kdump kernel for arm64 kdump, but the > '/chosen/kaslr-seed' property would be zeroed out already by the > primary kernel and the secondary would work in a *nokaslr* environment > due to the same (see [4] for example) > What would be the point of randomizing the placement of the kdump kernel? And don't say 'because x86 does it', because that is not a good reason. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
