[Query] ARM64 kaslr support - randomness, seeding and kdump

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

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.

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)

[1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L906
[2]. https://github.com/torvalds/linux/blob/master/arch/x86/lib/kaslr.c#L49
[3]. https://github.com/bhupesh-sharma/edk2-platforms/tree/master/Silicon/Openmoko/ChaosKeyDxe
[4]. https://elixir.bootlin.com/linux/v4.12.9/source/arch/arm64/kernel/kaslr.c#L104

Please share your views.

Regards,
Bhupesh

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

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.

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)

[1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L906
[2]. https://github.com/torvalds/linux/blob/master/arch/x86/lib/kaslr.c#L49
[3]. https://github.com/bhupesh-sharma/edk2-platforms/tree/master/Silicon/Openmoko/ChaosKeyDxe
[4]. https://elixir.bootlin.com/linux/v4.12.9/source/arch/arm64/kernel/kaslr.c#L104

Please share your views.

Regards,
Bhupesh

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Ard Biesheuvel]

On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Ard Biesheuvel]

On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Dave Young]

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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Dave Young]

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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote:
> > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> On Mon, Mar 12, 2018 at 08:58:00PM +0000, Ard Biesheuvel wrote:
> > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
>> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
>> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote:
> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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;
>         }
>     }
> ...
> }
> 
> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote:
> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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;
>         }
>     }
> ...
> }
> 
> 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 mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

'

On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> 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 <mark.rutland@arm.com> wrote:
>> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
>> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 valid, non-zero '/chosen/kaslr-seed' and
uses it to calculate the offsets for randomizing the linear region and
randomizing the base of the module region. Since the seed was a known
static value, determining the randomized bases of the above regions is
always possible.

So, I am not sure the existing 'kexec-tools' design can protect us
from such security vulnerabilities anyway as we rely on passing the
dtb to the secondary kernel for arm64 kexec to work.

What I was suggesting in the previous mail was that instead of passing
a zero '/chosen/kaslr-seed' to the secondary/kexec kernel (which
effectively leads to a *nokaslr* behaviour), we can do the right thing
by using a entropy source (if available) to generate a random seed.

> (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.)

I think we need to handle both the kexec_load() and kexec_file_load()
cases transparently as the user may invoke either of them.

Just for my understanding - in the arm64  kexec_file_load() case we
don't pass the modified dtb via user-space to the secondary kernel.
Right (sorry I still haven't looked at the latest kexec_file_load()
patches yet)?

Thanks,
Bhupesh

>
>> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

'

On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> 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 <mark.rutland@arm.com> wrote:
>> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
>> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 valid, non-zero '/chosen/kaslr-seed' and
uses it to calculate the offsets for randomizing the linear region and
randomizing the base of the module region. Since the seed was a known
static value, determining the randomized bases of the above regions is
always possible.

So, I am not sure the existing 'kexec-tools' design can protect us
from such security vulnerabilities anyway as we rely on passing the
dtb to the secondary kernel for arm64 kexec to work.

What I was suggesting in the previous mail was that instead of passing
a zero '/chosen/kaslr-seed' to the secondary/kexec kernel (which
effectively leads to a *nokaslr* behaviour), we can do the right thing
by using a entropy source (if available) to generate a random seed.

> (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.)

I think we need to handle both the kexec_load() and kexec_file_load()
cases transparently as the user may invoke either of them.

Just for my understanding - in the arm64  kexec_file_load() case we
don't pass the modified dtb via user-space to the secondary kernel.
Right (sorry I still haven't looked at the latest kexec_file_load()
patches yet)?

Thanks,
Bhupesh

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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Wed, Mar 14, 2018 at 10:33:03AM +0530, Bhupesh Sharma wrote:
> '
> 
> On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> 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 <mark.rutland@arm.com> wrote:
> >> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> >> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> >> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 valid, non-zero '/chosen/kaslr-seed' and
> uses it to calculate the offsets for randomizing the linear region and
> randomizing the base of the module region. Since the seed was a known
> static value, determining the randomized bases of the above regions is
> always possible.
> 
> So, I am not sure the existing 'kexec-tools' design can protect us
> from such security vulnerabilities anyway as we rely on passing the
> dtb to the secondary kernel for arm64 kexec to work.
> 
> What I was suggesting in the previous mail was that instead of passing
> a zero '/chosen/kaslr-seed' to the secondary/kexec kernel (which
> effectively leads to a *nokaslr* behaviour), we can do the right thing
> by using a entropy source (if available) to generate a random seed.

I will comment on those later if any.
> 
> > (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.)
> 
> I think we need to handle both the kexec_load() and kexec_file_load()
> cases transparently as the user may invoke either of them.
> 
> Just for my understanding - in the arm64  kexec_file_load() case we
> don't pass the modified dtb via user-space to the secondary kernel.
> Right (sorry I still haven't looked at the latest kexec_file_load()
> patches yet)?

Correct.
In kexec_file case, the 1st kernel is responsible for preparing
dtb for 2nd kernel by duplicating the current one and modifying
it if necessary.
As such, kexec_file hardly relies on kexec-tools.
(You know kexec-tools sources have not been well reviewed by anyone.)

Thanks,
-Takahiro AKASHI


> Thanks,
> Bhupesh
> 
> >
> >> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

On Wed, Mar 14, 2018 at 10:33:03AM +0530, Bhupesh Sharma wrote:
> '
> 
> On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> 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 <mark.rutland@arm.com> wrote:
> >> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> >> >> On Tue, Mar 13, 2018 at 10:47:15AM +0000, 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 +0000, Ard Biesheuvel wrote:
> >> >> > > > On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 valid, non-zero '/chosen/kaslr-seed' and
> uses it to calculate the offsets for randomizing the linear region and
> randomizing the base of the module region. Since the seed was a known
> static value, determining the randomized bases of the above regions is
> always possible.
> 
> So, I am not sure the existing 'kexec-tools' design can protect us
> from such security vulnerabilities anyway as we rely on passing the
> dtb to the secondary kernel for arm64 kexec to work.
> 
> What I was suggesting in the previous mail was that instead of passing
> a zero '/chosen/kaslr-seed' to the secondary/kexec kernel (which
> effectively leads to a *nokaslr* behaviour), we can do the right thing
> by using a entropy source (if available) to generate a random seed.

I will comment on those later if any.
> 
> > (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.)
> 
> I think we need to handle both the kexec_load() and kexec_file_load()
> cases transparently as the user may invoke either of them.
> 
> Just for my understanding - in the arm64  kexec_file_load() case we
> don't pass the modified dtb via user-space to the secondary kernel.
> Right (sorry I still haven't looked at the latest kexec_file_load()
> patches yet)?

Correct.
In kexec_file case, the 1st kernel is responsible for preparing
dtb for 2nd kernel by duplicating the current one and modifying
it if necessary.
As such, kexec_file hardly relies on kexec-tools.
(You know kexec-tools sources have not been well reviewed by anyone.)

Thanks,
-Takahiro AKASHI


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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

On Wed, Mar 14, 2018 at 11:54 PM, Mark Rutland <mark.rutland@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

On Wed, Mar 14, 2018 at 11:54 PM, Mark Rutland <mark.rutland@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Akashi,

On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> 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@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Akashi,

On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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@linaro.org> 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@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Ard Biesheuvel]

On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
>> <takahiro.akashi@linaro.org> 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@arm.com> 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?

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Ard Biesheuvel]

On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
>> <takahiro.akashi@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Baoquan He]

On 04/09/18 at 11:28am, Ard Biesheuvel wrote:
> On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
> >> <takahiro.akashi@linaro.org> 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@arm.com> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Baoquan He]

On 04/09/18 at 11:28am, Ard Biesheuvel wrote:
> On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
> >> <takahiro.akashi@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Ard,

On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
>>> <takahiro.akashi@linaro.org> 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@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Ard,

On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
>>> <takahiro.akashi@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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
> <ard.biesheuvel@linaro.org> wrote:
> > On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
> >>> <takahiro.akashi@linaro.org> 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@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[AKASHI Takahiro]

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
> <ard.biesheuvel@linaro.org> wrote:
> > On 9 April 2018 at 06:31, AKASHI Takahiro <takahiro.akashi@linaro.org> 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
> >>> <takahiro.akashi@linaro.org> 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@arm.com> 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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Ard,

On Tue, Mar 13, 2018 at 2:28 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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 at 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Ard,

On Tue, Mar 13, 2018 at 2:28 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma <bhsharma@redhat.com> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

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.

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Mark Rutland]

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

[Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Mark,

On Wed, Apr 18, 2018 at 5:22 PM, Mark Rutland <mark.rutland@arm.com> 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

Re: [Query] ARM64 kaslr support - randomness, seeding and kdump

[Bhupesh Sharma]

Hi Mark,

On Wed, Apr 18, 2018 at 5:22 PM, Mark Rutland <mark.rutland@arm.com> 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