Hi Dave,
On Tue, Oct 23, 2018 at 7:01 AM Dave Young <dyoung@xxxxxxxxxx> wrote:
>
> Hi Bhupesh,
>
> On 10/23/18 at 01:50am, Bhupesh Sharma wrote:
> > For calculating the random 'kaslr-seed' value to be passed to the
> > secondary kernel (kexec or kdump), we invoke the 'getrandom' syscall
> > inside 'setup_2nd_dtb()' function.
> >
> > Normally on most arm64 systems this syscall doesn't fail when the
> > initrd scriptware (which arms kdump service) invokes the same.
> > However, recently I noticed that on the 'hp-moonshot' arm64 boards,
> > we have an issue with the newer kernels which causes the same
> > to fail. As a result, the kdump service fails and we are not able
> > to use the kdump infrastructure just after boot. As expected, once the
> > random pool is sufficiently populated and we launch the kdump service
> > arming scripts again (manually), then the kdump service is properly
> > enabled.
> >
> > Lets handle the same, by not error'ing out if 'getrandom' syscall fails.
> > Rather lets warn the user and proceed further by setting the
> > 'kaslr-seed' value as 0 for the secondary kernel - which implies that it
> > boots in a 'nokaslr' mode.
>
> kaslr is meaningless for kdump, so it would be good to print the message
> only for kexec reboot or just do not try to setup the seed for kdump
> loading.
Thanks for your comments.
We discussed some background about this during the review of patch
"arm64: Add support to supply 'kaslr-seed' to secondary kernel", which
is now commit c3f043241a866a7af9117396634dfcb20f0fd9cb.
Ideally, one would want to keep the secondary kernel behaviour similar
from a p-o-v of how the DTB is being populated by 'kexec-tools' for
the secondary kernel, irrespective of whether we are doing a kexec
warm boot or kdump arming.
In addition, some users on Freescale/NXP arm64 boards requested the
same as they use KASLR feature in the 'kexec -p' (kdump) use cases on
their boards. So, I would suggest that we don't break such use-cases
on arm64 boards via booting kdump kernel in 'nokaslr' mode - if one
needs to do the same they can pass 'nokaslr' explicitly in the
bootrags being passed to the kdump kernel.
Hope this clarify the intent behind this patch.
Regards,
Bhupesh
> >
> > Tested on my 'hp-moonshot' and 'qualcomm-amberwing' arm64 boards.
> >
> > Signed-off-by: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
> > ---
> > kexec/arch/arm64/kexec-arm64.c | 17 ++++++++++++++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> > index 7a124795f3d0..b143e861f7d9 100644
> > --- a/kexec/arch/arm64/kexec-arm64.c
> > +++ b/kexec/arch/arm64/kexec-arm64.c
> > @@ -492,10 +492,21 @@ static int setup_2nd_dtb(struct dtb *dtb, char *command_line, int on_crash)
> > GRND_NONBLOCK);
> >
> > if(result == -1) {
> > - dbgprintf("%s: Reading random bytes failed.\n",
> > + fprintf(stderr, "%s: Reading random bytes failed.\n",
> > + __func__);
> > +
> > + /* Currently on some arm64 platforms this
> > + * 'getrandom' system call fails while booting
> > + * the platform.
> > + *
> > + * In case, this happens at best we can set
> > + * the 'kaslr_seed' as 0, indicating that the
> > + * 2nd kernel will be booted with a 'nokaslr'
> > + * like behaviour.
> > + */
> > + fdt_val64 = 0UL;
> > + dbgprintf("%s: Disabling KASLR in secondary kernel.\n",
> > __func__);
> > - result = -EINVAL;
> > - goto on_error;
> > }
> >
> > nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > --
> > 2.7.4
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@xxxxxxxxxxxxxxxxxxx
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
