* Re: [PATCH] kexec: Add --lite option
2015-10-21 23:12 [PATCH] kexec: Add --lite option Geoff Levand
@ 2015-10-22 0:02 ` Jeremy Kerr
2015-10-22 0:37 ` Geoff Levand
2015-10-22 3:17 ` Dave Young
2018-04-11 18:30 ` [PATCH v2] kexec: Add --no-checks option Geoff Levand
2 siblings, 1 reply; 32+ messages in thread
From: Jeremy Kerr @ 2015-10-22 0:02 UTC (permalink / raw)
To: Geoff Levand, Simon Horman; +Cc: kexec, Anton Blanchard, Petitboot
Hi Geoff,
> Add a new option --lite to kexec that allows for a fast reboot
> by avoiding the purgatory integrity checks. This option is
> intended for use by kexec based bootloaders that load a new
> image and then immediately transfer control to it.
Can we call this something other than 'lite'? I'd want to prevent any
confusion when referring to 'kexec-lite', which is a separate project.
Cheers,
Jeremy
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi Simon,
>
> It was reported that on some systems where purgatory is running
> without caches enabled the sha256 calculations would take several
> minutes. For bootloaders that just load a new image and
> immediately jump into it the loss of the integrity check is worth
> the increase in boot speed. Please consider.
>
> -Geoff
>
> kexec/kexec.8 | 3 +++
> kexec/kexec.c | 19 +++++++++++++++++--
> kexec/kexec.h | 4 ++++
> purgatory/purgatory.c | 3 ++-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/kexec/kexec.8 b/kexec/kexec.8
> index 4d0c1d1..93ed588 100644
> --- a/kexec/kexec.8
> +++ b/kexec/kexec.8
> @@ -126,6 +126,9 @@ in one call.
> Open a help file for
> .BR kexec .
> .TP
> +.B \-i\ (\-\-lite)
> +Fast reboot, no memory integrity checks.
> +.TP
> .BI \-l\ (\-\-load) \ kernel
> Load the specified
> .I kernel
> diff --git a/kexec/kexec.c b/kexec/kexec.c
> index ff024f3..ebb1310 100644
> --- a/kexec/kexec.c
> +++ b/kexec/kexec.c
> @@ -613,6 +613,15 @@ static void update_purgatory(struct kexec_info *info)
> return;
> }
> arch_update_purgatory(info);
> +
> + if (info->kexec_lite) {
> + unsigned int tmp = 1;
> +
> + elf_rel_set_symbol(&info->rhdr, "kexec_lite", &tmp,
> + sizeof(tmp));
> + return;
> + }
> +
> memset(region, 0, sizeof(region));
> sha256_starts(&ctx);
> /* Compute a hash of the loaded kernel */
> @@ -652,7 +661,7 @@ static void update_purgatory(struct kexec_info *info)
> * Load the new kernel
> */
> static int my_load(const char *type, int fileind, int argc, char **argv,
> - unsigned long kexec_flags, void *entry)
> + unsigned long kexec_flags, int kexec_lite, void *entry)
> {
> char *kernel;
> char *kernel_buf;
> @@ -665,6 +674,7 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
>
> memset(&info, 0, sizeof(info));
> info.kexec_flags = kexec_flags;
> + info.kexec_lite = kexec_lite;
>
> result = 0;
> if (argc - fileind <= 0) {
> @@ -914,6 +924,7 @@ void usage(void)
> " -v, --version Print the version of kexec.\n"
> " -f, --force Force an immediate kexec,\n"
> " don't call shutdown.\n"
> + " -i, --lite Fast reboot, no memory integrity checks.\n"
> " -x, --no-ifdown Don't bring down network interfaces.\n"
> " -y, --no-sync Don't sync filesystems before kexec.\n"
> " -l, --load Load the new kernel into the\n"
> @@ -1173,6 +1184,7 @@ int main(int argc, char *argv[])
> int do_unload = 0;
> int do_reuse_initrd = 0;
> int do_kexec_file_syscall = 0;
> + int do_lite = 0;
> void *entry = 0;
> char *type = 0;
> char *endptr;
> @@ -1314,6 +1326,9 @@ int main(int argc, char *argv[])
> case OPT_KEXEC_FILE_SYSCALL:
> /* We already parsed it. Nothing to do. */
> break;
> + case OPT_LITE:
> + do_lite = 1;
> + break;
> default:
> break;
> }
> @@ -1374,7 +1389,7 @@ int main(int argc, char *argv[])
> kexec_file_flags);
> else
> result = my_load(type, fileind, argc, argv,
> - kexec_flags, entry);
> + kexec_flags, do_lite, entry);
> }
> /* Don't shutdown unless there is something to reboot to! */
> if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded()) {
> diff --git a/kexec/kexec.h b/kexec/kexec.h
> index 7c97b25..06e08f4 100644
> --- a/kexec/kexec.h
> +++ b/kexec/kexec.h
> @@ -165,6 +165,8 @@ struct kexec_info {
> int initrd_fd;
> char *command_line;
> int command_line_len;
> +
> + int kexec_lite;
> };
>
> struct arch_map_entry {
> @@ -218,6 +220,7 @@ extern int file_types;
> #define OPT_TYPE 't'
> #define OPT_PANIC 'p'
> #define OPT_KEXEC_FILE_SYSCALL 's'
> +#define OPT_LITE 'i'
> #define OPT_MEM_MIN 256
> #define OPT_MEM_MAX 257
> #define OPT_REUSE_INITRD 258
> @@ -243,6 +246,7 @@ extern int file_types;
> { "mem-max", 1, 0, OPT_MEM_MAX }, \
> { "reuseinitrd", 0, 0, OPT_REUSE_INITRD }, \
> { "kexec-file-syscall", 0, 0, OPT_KEXEC_FILE_SYSCALL }, \
> + { "lite", 0, 0, OPT_LITE }, \
> { "debug", 0, 0, OPT_DEBUG }, \
>
> #define KEXEC_OPT_STR "h?vdfxyluet:ps"
> diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
> index 3bbcc09..7e99b92 100644
> --- a/purgatory/purgatory.c
> +++ b/purgatory/purgatory.c
> @@ -8,6 +8,7 @@
>
> struct sha256_region sha256_regions[SHA256_REGIONS] = {};
> sha256_digest_t sha256_digest = { };
> +int kexec_lite = 0;
>
> int verify_sha256_digest(void)
> {
> @@ -43,7 +44,7 @@ void purgatory(void)
> {
> printf("I'm in purgatory\n");
> setup_arch();
> - if (verify_sha256_digest()) {
> + if (!kexec_lite && verify_sha256_digest()) {
> for(;;) {
> /* loop forever */
> }
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
2015-10-22 0:02 ` Jeremy Kerr
@ 2015-10-22 0:37 ` Geoff Levand
2015-11-05 6:20 ` Scott Wood
0 siblings, 1 reply; 32+ messages in thread
From: Geoff Levand @ 2015-10-22 0:37 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: kexec, Anton Blanchard, Petitboot
Hi Jeremy,
On Thu, 2015-10-22 at 08:02 +0800, Jeremy Kerr wrote:
> Add a new option --lite to kexec that allows for a fast reboot
> > by avoiding the purgatory integrity checks. This option is
> > intended for use by kexec based bootloaders that load a new
> > image and then immediately transfer control to it.
>
> Can we call this something other than 'lite'? I'd want to prevent any
> confusion when referring to 'kexec-lite', which is a separate
> project.
Well, that is why I chose the name 'lite', because it mimics what kexec
-lite does...
What do others think?
-Geoff
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-22 0:37 ` Geoff Levand
@ 2015-11-05 6:20 ` Scott Wood
0 siblings, 0 replies; 32+ messages in thread
From: Scott Wood @ 2015-11-05 6:20 UTC (permalink / raw)
To: Geoff Levand; +Cc: kexec, Jeremy Kerr, Petitboot, Anton Blanchard
On Wed, 2015-10-21 at 17:37 -0700, Geoff Levand wrote:
> Hi Jeremy,
>
> On Thu, 2015-10-22 at 08:02 +0800, Jeremy Kerr wrote:
> > Add a new option --lite to kexec that allows for a fast reboot
> > > by avoiding the purgatory integrity checks. This option is
> > > intended for use by kexec based bootloaders that load a new
> > > image and then immediately transfer control to it.
> >
> > Can we call this something other than 'lite'? I'd want to prevent any
> > confusion when referring to 'kexec-lite', which is a separate
> > project.
>
> Well, that is why I chose the name 'lite', because it mimics what kexec
> -lite does...
>
> What do others think?
I don't think it's a good name. Even if the user has any idea what the kexec-
lite project is and that this is a reference to it, you're mimicking a
specific aspect of kexec-lite behavior, not kexec-lite in general.
If it's an option to skip sha256 verification, then call it something like "--
skip-sha256".
-Scott
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-21 23:12 [PATCH] kexec: Add --lite option Geoff Levand
2015-10-22 0:02 ` Jeremy Kerr
@ 2015-10-22 3:17 ` Dave Young
2015-10-22 12:50 ` Vivek Goyal
2015-10-22 18:57 ` Geoff Levand
2018-04-11 18:30 ` [PATCH v2] kexec: Add --no-checks option Geoff Levand
2 siblings, 2 replies; 32+ messages in thread
From: Dave Young @ 2015-10-22 3:17 UTC (permalink / raw)
To: Geoff Levand; +Cc: panand, Simon Horman, kexec, Petitboot, vgoyal
On 10/21/15 at 04:12pm, Geoff Levand wrote:
> Add a new option --lite to kexec that allows for a fast reboot
> by avoiding the purgatory integrity checks. This option is
> intended for use by kexec based bootloaders that load a new
> image and then immediately transfer control to it.
I think Vivek was rejecting this --lite since kdump need the purgatory
integrity checks. Ccing him.
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi Simon,
>
> It was reported that on some systems where purgatory is running
> without caches enabled the sha256 calculations would take several
> minutes. For bootloaders that just load a new image and
> immediately jump into it the loss of the integrity check is worth
> the increase in boot speed. Please consider.
Pratyush reported the arm64 issue, he sent a patch to fix it with
enabling cache for purgatory. I think the patch can fix the problem.
Why not fix it? The fix is simple enough and it does not introduce
complicate logic.
>
> -Geoff
>
> kexec/kexec.8 | 3 +++
> kexec/kexec.c | 19 +++++++++++++++++--
> kexec/kexec.h | 4 ++++
> purgatory/purgatory.c | 3 ++-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/kexec/kexec.8 b/kexec/kexec.8
> index 4d0c1d1..93ed588 100644
> --- a/kexec/kexec.8
> +++ b/kexec/kexec.8
> @@ -126,6 +126,9 @@ in one call.
> Open a help file for
> .BR kexec .
> .TP
> +.B \-i\ (\-\-lite)
> +Fast reboot, no memory integrity checks.
> +.TP
> .BI \-l\ (\-\-load) \ kernel
> Load the specified
> .I kernel
> diff --git a/kexec/kexec.c b/kexec/kexec.c
> index ff024f3..ebb1310 100644
> --- a/kexec/kexec.c
> +++ b/kexec/kexec.c
> @@ -613,6 +613,15 @@ static void update_purgatory(struct kexec_info *info)
> return;
> }
> arch_update_purgatory(info);
> +
> + if (info->kexec_lite) {
> + unsigned int tmp = 1;
> +
> + elf_rel_set_symbol(&info->rhdr, "kexec_lite", &tmp,
> + sizeof(tmp));
> + return;
> + }
> +
> memset(region, 0, sizeof(region));
> sha256_starts(&ctx);
> /* Compute a hash of the loaded kernel */
> @@ -652,7 +661,7 @@ static void update_purgatory(struct kexec_info *info)
> * Load the new kernel
> */
> static int my_load(const char *type, int fileind, int argc, char **argv,
> - unsigned long kexec_flags, void *entry)
> + unsigned long kexec_flags, int kexec_lite, void *entry)
> {
> char *kernel;
> char *kernel_buf;
> @@ -665,6 +674,7 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
>
> memset(&info, 0, sizeof(info));
> info.kexec_flags = kexec_flags;
> + info.kexec_lite = kexec_lite;
>
> result = 0;
> if (argc - fileind <= 0) {
> @@ -914,6 +924,7 @@ void usage(void)
> " -v, --version Print the version of kexec.\n"
> " -f, --force Force an immediate kexec,\n"
> " don't call shutdown.\n"
> + " -i, --lite Fast reboot, no memory integrity checks.\n"
> " -x, --no-ifdown Don't bring down network interfaces.\n"
> " -y, --no-sync Don't sync filesystems before kexec.\n"
> " -l, --load Load the new kernel into the\n"
> @@ -1173,6 +1184,7 @@ int main(int argc, char *argv[])
> int do_unload = 0;
> int do_reuse_initrd = 0;
> int do_kexec_file_syscall = 0;
> + int do_lite = 0;
> void *entry = 0;
> char *type = 0;
> char *endptr;
> @@ -1314,6 +1326,9 @@ int main(int argc, char *argv[])
> case OPT_KEXEC_FILE_SYSCALL:
> /* We already parsed it. Nothing to do. */
> break;
> + case OPT_LITE:
> + do_lite = 1;
> + break;
> default:
> break;
> }
> @@ -1374,7 +1389,7 @@ int main(int argc, char *argv[])
> kexec_file_flags);
> else
> result = my_load(type, fileind, argc, argv,
> - kexec_flags, entry);
> + kexec_flags, do_lite, entry);
> }
> /* Don't shutdown unless there is something to reboot to! */
> if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded()) {
> diff --git a/kexec/kexec.h b/kexec/kexec.h
> index 7c97b25..06e08f4 100644
> --- a/kexec/kexec.h
> +++ b/kexec/kexec.h
> @@ -165,6 +165,8 @@ struct kexec_info {
> int initrd_fd;
> char *command_line;
> int command_line_len;
> +
> + int kexec_lite;
> };
>
> struct arch_map_entry {
> @@ -218,6 +220,7 @@ extern int file_types;
> #define OPT_TYPE 't'
> #define OPT_PANIC 'p'
> #define OPT_KEXEC_FILE_SYSCALL 's'
> +#define OPT_LITE 'i'
> #define OPT_MEM_MIN 256
> #define OPT_MEM_MAX 257
> #define OPT_REUSE_INITRD 258
> @@ -243,6 +246,7 @@ extern int file_types;
> { "mem-max", 1, 0, OPT_MEM_MAX }, \
> { "reuseinitrd", 0, 0, OPT_REUSE_INITRD }, \
> { "kexec-file-syscall", 0, 0, OPT_KEXEC_FILE_SYSCALL }, \
> + { "lite", 0, 0, OPT_LITE }, \
> { "debug", 0, 0, OPT_DEBUG }, \
>
> #define KEXEC_OPT_STR "h?vdfxyluet:ps"
> diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
> index 3bbcc09..7e99b92 100644
> --- a/purgatory/purgatory.c
> +++ b/purgatory/purgatory.c
> @@ -8,6 +8,7 @@
>
> struct sha256_region sha256_regions[SHA256_REGIONS] = {};
> sha256_digest_t sha256_digest = { };
> +int kexec_lite = 0;
>
> int verify_sha256_digest(void)
> {
> @@ -43,7 +44,7 @@ void purgatory(void)
> {
> printf("I'm in purgatory\n");
> setup_arch();
> - if (verify_sha256_digest()) {
> + if (!kexec_lite && verify_sha256_digest()) {
> for(;;) {
> /* loop forever */
> }
> --
> 2.5.0
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
2015-10-22 3:17 ` Dave Young
@ 2015-10-22 12:50 ` Vivek Goyal
2015-10-22 19:08 ` Geoff Levand
2015-10-22 18:57 ` Geoff Levand
1 sibling, 1 reply; 32+ messages in thread
From: Vivek Goyal @ 2015-10-22 12:50 UTC (permalink / raw)
To: Dave Young; +Cc: Geoff Levand, panand, Simon Horman, kexec, Petitboot
On Thu, Oct 22, 2015 at 11:17:18AM +0800, Dave Young wrote:
> On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > Add a new option --lite to kexec that allows for a fast reboot
> > by avoiding the purgatory integrity checks. This option is
> > intended for use by kexec based bootloaders that load a new
> > image and then immediately transfer control to it.
>
> I think Vivek was rejecting this --lite since kdump need the purgatory
> integrity checks. Ccing him.
Right. Why are we trying to bypass sha256 hash verification of loaded
segments at run time, that needs to be justified.
Atleast on x86, this integrity verification was fast and we did not
notice any siginificant delays in purgatory. And in that case extra knob
like this is hard to justify.
Thanks
Vivek
>
> >
> > Signed-off-by: Geoff Levand <geoff@infradead.org>
> > ---
> > Hi Simon,
> >
> > It was reported that on some systems where purgatory is running
> > without caches enabled the sha256 calculations would take several
> > minutes. For bootloaders that just load a new image and
> > immediately jump into it the loss of the integrity check is worth
> > the increase in boot speed. Please consider.
>
> Pratyush reported the arm64 issue, he sent a patch to fix it with
> enabling cache for purgatory. I think the patch can fix the problem.
> Why not fix it? The fix is simple enough and it does not introduce
> complicate logic.
>
> >
> > -Geoff
> >
> > kexec/kexec.8 | 3 +++
> > kexec/kexec.c | 19 +++++++++++++++++--
> > kexec/kexec.h | 4 ++++
> > purgatory/purgatory.c | 3 ++-
> > 4 files changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/kexec/kexec.8 b/kexec/kexec.8
> > index 4d0c1d1..93ed588 100644
> > --- a/kexec/kexec.8
> > +++ b/kexec/kexec.8
> > @@ -126,6 +126,9 @@ in one call.
> > Open a help file for
> > .BR kexec .
> > .TP
> > +.B \-i\ (\-\-lite)
> > +Fast reboot, no memory integrity checks.
> > +.TP
> > .BI \-l\ (\-\-load) \ kernel
> > Load the specified
> > .I kernel
> > diff --git a/kexec/kexec.c b/kexec/kexec.c
> > index ff024f3..ebb1310 100644
> > --- a/kexec/kexec.c
> > +++ b/kexec/kexec.c
> > @@ -613,6 +613,15 @@ static void update_purgatory(struct kexec_info *info)
> > return;
> > }
> > arch_update_purgatory(info);
> > +
> > + if (info->kexec_lite) {
> > + unsigned int tmp = 1;
> > +
> > + elf_rel_set_symbol(&info->rhdr, "kexec_lite", &tmp,
> > + sizeof(tmp));
> > + return;
> > + }
> > +
> > memset(region, 0, sizeof(region));
> > sha256_starts(&ctx);
> > /* Compute a hash of the loaded kernel */
> > @@ -652,7 +661,7 @@ static void update_purgatory(struct kexec_info *info)
> > * Load the new kernel
> > */
> > static int my_load(const char *type, int fileind, int argc, char **argv,
> > - unsigned long kexec_flags, void *entry)
> > + unsigned long kexec_flags, int kexec_lite, void *entry)
> > {
> > char *kernel;
> > char *kernel_buf;
> > @@ -665,6 +674,7 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
> >
> > memset(&info, 0, sizeof(info));
> > info.kexec_flags = kexec_flags;
> > + info.kexec_lite = kexec_lite;
> >
> > result = 0;
> > if (argc - fileind <= 0) {
> > @@ -914,6 +924,7 @@ void usage(void)
> > " -v, --version Print the version of kexec.\n"
> > " -f, --force Force an immediate kexec,\n"
> > " don't call shutdown.\n"
> > + " -i, --lite Fast reboot, no memory integrity checks.\n"
> > " -x, --no-ifdown Don't bring down network interfaces.\n"
> > " -y, --no-sync Don't sync filesystems before kexec.\n"
> > " -l, --load Load the new kernel into the\n"
> > @@ -1173,6 +1184,7 @@ int main(int argc, char *argv[])
> > int do_unload = 0;
> > int do_reuse_initrd = 0;
> > int do_kexec_file_syscall = 0;
> > + int do_lite = 0;
> > void *entry = 0;
> > char *type = 0;
> > char *endptr;
> > @@ -1314,6 +1326,9 @@ int main(int argc, char *argv[])
> > case OPT_KEXEC_FILE_SYSCALL:
> > /* We already parsed it. Nothing to do. */
> > break;
> > + case OPT_LITE:
> > + do_lite = 1;
> > + break;
> > default:
> > break;
> > }
> > @@ -1374,7 +1389,7 @@ int main(int argc, char *argv[])
> > kexec_file_flags);
> > else
> > result = my_load(type, fileind, argc, argv,
> > - kexec_flags, entry);
> > + kexec_flags, do_lite, entry);
> > }
> > /* Don't shutdown unless there is something to reboot to! */
> > if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded()) {
> > diff --git a/kexec/kexec.h b/kexec/kexec.h
> > index 7c97b25..06e08f4 100644
> > --- a/kexec/kexec.h
> > +++ b/kexec/kexec.h
> > @@ -165,6 +165,8 @@ struct kexec_info {
> > int initrd_fd;
> > char *command_line;
> > int command_line_len;
> > +
> > + int kexec_lite;
> > };
> >
> > struct arch_map_entry {
> > @@ -218,6 +220,7 @@ extern int file_types;
> > #define OPT_TYPE 't'
> > #define OPT_PANIC 'p'
> > #define OPT_KEXEC_FILE_SYSCALL 's'
> > +#define OPT_LITE 'i'
> > #define OPT_MEM_MIN 256
> > #define OPT_MEM_MAX 257
> > #define OPT_REUSE_INITRD 258
> > @@ -243,6 +246,7 @@ extern int file_types;
> > { "mem-max", 1, 0, OPT_MEM_MAX }, \
> > { "reuseinitrd", 0, 0, OPT_REUSE_INITRD }, \
> > { "kexec-file-syscall", 0, 0, OPT_KEXEC_FILE_SYSCALL }, \
> > + { "lite", 0, 0, OPT_LITE }, \
> > { "debug", 0, 0, OPT_DEBUG }, \
> >
> > #define KEXEC_OPT_STR "h?vdfxyluet:ps"
> > diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
> > index 3bbcc09..7e99b92 100644
> > --- a/purgatory/purgatory.c
> > +++ b/purgatory/purgatory.c
> > @@ -8,6 +8,7 @@
> >
> > struct sha256_region sha256_regions[SHA256_REGIONS] = {};
> > sha256_digest_t sha256_digest = { };
> > +int kexec_lite = 0;
> >
> > int verify_sha256_digest(void)
> > {
> > @@ -43,7 +44,7 @@ void purgatory(void)
> > {
> > printf("I'm in purgatory\n");
> > setup_arch();
> > - if (verify_sha256_digest()) {
> > + if (!kexec_lite && verify_sha256_digest()) {
> > for(;;) {
> > /* loop forever */
> > }
> > --
> > 2.5.0
> >
> >
> > _______________________________________________
> > 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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
2015-10-22 12:50 ` Vivek Goyal
@ 2015-10-22 19:08 ` Geoff Levand
2015-11-05 5:56 ` Scott Wood
0 siblings, 1 reply; 32+ messages in thread
From: Geoff Levand @ 2015-10-22 19:08 UTC (permalink / raw)
To: Vivek Goyal, Dave Young; +Cc: panand, Simon Horman, kexec, Petitboot
Hi Vivek,
On Thu, 2015-10-22 at 08:50 -0400, Vivek Goyal wrote:
> On Thu, Oct 22, 2015 at 11:17:18AM +0800, Dave Young wrote:
> > On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > > Add a new option --lite to kexec that allows for a fast reboot
> > > by avoiding the purgatory integrity checks. This option is
> > > intended for use by kexec based bootloaders that load a new
> > > image and then immediately transfer control to it.
> >
> > I think Vivek was rejecting this --lite since kdump need the purgatory
> > integrity checks. Ccing him.
>
> Right. Why are we trying to bypass sha256 hash verification of loaded
> segments at run time, that needs to be justified.
Please see my reply to Dave.
> Atleast on x86, this integrity verification was fast and we did not
> notice any siginificant delays in purgatory. And in that case extra knob
> like this is hard to justify.
I notice the difference on the my arm64 system, so I guess we
are even on that.
In general, faster boot times are desirable. This option allows
a faster system boot for kexec based bootloaders that use
kexec-tools.
-Geoff
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-22 19:08 ` Geoff Levand
@ 2015-11-05 5:56 ` Scott Wood
2015-12-07 11:45 ` Pratyush Anand
0 siblings, 1 reply; 32+ messages in thread
From: Scott Wood @ 2015-11-05 5:56 UTC (permalink / raw)
To: Geoff Levand
Cc: panand, kexec, Simon Horman, Petitboot, Dave Young, Vivek Goyal
On Thu, 2015-10-22 at 12:08 -0700, Geoff Levand wrote:
> Hi Vivek,
>
> On Thu, 2015-10-22 at 08:50 -0400, Vivek Goyal wrote:
> > On Thu, Oct 22, 2015 at 11:17:18AM +0800, Dave Young wrote:
> > > On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > > > Add a new option --lite to kexec that allows for a fast reboot
> > > > by avoiding the purgatory integrity checks. This option is
> > > > intended for use by kexec based bootloaders that load a new
> > > > image and then immediately transfer control to it.
> > >
> > > I think Vivek was rejecting this --lite since kdump need the purgatory
> > > integrity checks. Ccing him.
> >
> > Right. Why are we trying to bypass sha256 hash verification of loaded
> > segments at run time, that needs to be justified.
>
> Please see my reply to Dave.
>
> > Atleast on x86, this integrity verification was fast and we did not
> > notice any siginificant delays in purgatory. And in that case extra knob
> > like this is hard to justify.
>
> I notice the difference on the my arm64 system, so I guess we
> are even on that.
For me it was beyond "notice the difference" -- I thought it was completely
broken, and was preparing to debug, until it started spitting out output over
a minute later.
Compiling the sha256 code with -O2 instead of -O0 cut it down to around 10
seconds (still unpleasant, but not quite as crazy... still unacceptable for
non-kdump, though). There was a patch posted a couple years ago to do that --
does anyone know what happened to it?
http://kexec.infradead.narkive.com/JSemzXoT/patch-purgatory-compile-sha256-c-only-on-ia64-with-o0
-Scott
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-11-05 5:56 ` Scott Wood
@ 2015-12-07 11:45 ` Pratyush Anand
2015-12-07 11:48 ` Pratyush Anand
0 siblings, 1 reply; 32+ messages in thread
From: Pratyush Anand @ 2015-12-07 11:45 UTC (permalink / raw)
To: Scott Wood
Cc: Geoff Levand, kexec, Simon Horman, Petitboot, Dave Young, Vivek Goyal
+linux-arm-kernel@lists.infradead.org (May be someone from arm kernel list can
give some more input)
On 04/11/2015:11:56:51 PM, Scott Wood wrote:
> On Thu, 2015-10-22 at 12:08 -0700, Geoff Levand wrote:
> > I notice the difference on the my arm64 system, so I guess we
> > are even on that.
>
> For me it was beyond "notice the difference" -- I thought it was completely
> broken, and was preparing to debug, until it started spitting out output over
> a minute later.
>
> Compiling the sha256 code with -O2 instead of -O0 cut it down to around 10
> seconds (still unpleasant, but not quite as crazy... still unacceptable for
> non-kdump, though).
Yes, compiling purgatory code with -O2 helps to improve the timing, and I notice
that enabling D-cache on top of -O2 does not improve it further. However, I am
still not able to understand that why there is huge difference between following
two.
1) When we execute kexec() system call in first kernel, at that time it
calculates sha256 on all the binaries [1]. It take almost un-noticeable time
(less than a sec) there.
2) When purgatory is executed then it re-calculates sha256 using same routines
[2] on same binary data as that of case (1). But, now it takes 10-20 sec
(depending of size of binaries)?
Why did not it take same time with O2 + D-cache enabled? I think, we should be
able to achieve same time in second case as well. What is missing?
~Pratyush
[1] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec.c#n650
[2] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/purgatory/purgatory.c#n20
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] kexec: Add --lite option
2015-12-07 11:45 ` Pratyush Anand
@ 2015-12-07 11:48 ` Pratyush Anand
0 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-07 11:48 UTC (permalink / raw)
To: linux-arm-kernel
Sorry, forgot to add linux-arm-kernel at lists.infradead.org. Now CCed.
On 07/12/2015:05:15:47 PM, Pratyush Anand wrote:
> +linux-arm-kernel at lists.infradead.org (May be someone from arm kernel list can
> give some more input)
>
> On 04/11/2015:11:56:51 PM, Scott Wood wrote:
> > On Thu, 2015-10-22 at 12:08 -0700, Geoff Levand wrote:
> > > I notice the difference on the my arm64 system, so I guess we
> > > are even on that.
> >
> > For me it was beyond "notice the difference" -- I thought it was completely
> > broken, and was preparing to debug, until it started spitting out output over
> > a minute later.
> >
> > Compiling the sha256 code with -O2 instead of -O0 cut it down to around 10
> > seconds (still unpleasant, but not quite as crazy... still unacceptable for
> > non-kdump, though).
>
> Yes, compiling purgatory code with -O2 helps to improve the timing, and I notice
> that enabling D-cache on top of -O2 does not improve it further. However, I am
> still not able to understand that why there is huge difference between following
> two.
>
> 1) When we execute kexec() system call in first kernel, at that time it
> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
> (less than a sec) there.
>
> 2) When purgatory is executed then it re-calculates sha256 using same routines
> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
> (depending of size of binaries)?
>
> Why did not it take same time with O2 + D-cache enabled? I think, we should be
> able to achieve same time in second case as well. What is missing?
>
> ~Pratyush
>
> [1] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec.c#n650
> [2] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/purgatory/purgatory.c#n20
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
@ 2015-12-07 11:48 ` Pratyush Anand
0 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-07 11:48 UTC (permalink / raw)
To: Scott Wood
Cc: Geoff Levand, kexec, Simon Horman, linux-arm-kernel, Petitboot,
Dave Young, Vivek Goyal
Sorry, forgot to add linux-arm-kernel@lists.infradead.org. Now CCed.
On 07/12/2015:05:15:47 PM, Pratyush Anand wrote:
> +linux-arm-kernel@lists.infradead.org (May be someone from arm kernel list can
> give some more input)
>
> On 04/11/2015:11:56:51 PM, Scott Wood wrote:
> > On Thu, 2015-10-22 at 12:08 -0700, Geoff Levand wrote:
> > > I notice the difference on the my arm64 system, so I guess we
> > > are even on that.
> >
> > For me it was beyond "notice the difference" -- I thought it was completely
> > broken, and was preparing to debug, until it started spitting out output over
> > a minute later.
> >
> > Compiling the sha256 code with -O2 instead of -O0 cut it down to around 10
> > seconds (still unpleasant, but not quite as crazy... still unacceptable for
> > non-kdump, though).
>
> Yes, compiling purgatory code with -O2 helps to improve the timing, and I notice
> that enabling D-cache on top of -O2 does not improve it further. However, I am
> still not able to understand that why there is huge difference between following
> two.
>
> 1) When we execute kexec() system call in first kernel, at that time it
> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
> (less than a sec) there.
>
> 2) When purgatory is executed then it re-calculates sha256 using same routines
> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
> (depending of size of binaries)?
>
> Why did not it take same time with O2 + D-cache enabled? I think, we should be
> able to achieve same time in second case as well. What is missing?
>
> ~Pratyush
>
> [1] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec.c#n650
> [2] http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/purgatory/purgatory.c#n20
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] kexec: Add --lite option
2015-12-07 11:48 ` Pratyush Anand
@ 2015-12-07 13:16 ` James Morse
-1 siblings, 0 replies; 32+ messages in thread
From: James Morse @ 2015-12-07 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Pratyush,
On 07/12/15 11:48, Pratyush Anand wrote:
>> 1) When we execute kexec() system call in first kernel, at that time it
>> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
>> (less than a sec) there.
>>
>> 2) When purgatory is executed then it re-calculates sha256 using same routines
>> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
>> (depending of size of binaries)?
>>
>> Why did not it take same time with O2 + D-cache enabled? I think, we should be
>> able to achieve same time in second case as well. What is missing?
I haven't benchmarked this, but:
util_lib/sha256.c contains calls out to memcpy().
In your case 1, this will use the glibc version. In case 2, it will use
the version implemented in purgatory/string.c, which is a byte-by-byte copy.
Thanks,
James
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
@ 2015-12-07 13:16 ` James Morse
0 siblings, 0 replies; 32+ messages in thread
From: James Morse @ 2015-12-07 13:16 UTC (permalink / raw)
To: Pratyush Anand
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel
Hi Pratyush,
On 07/12/15 11:48, Pratyush Anand wrote:
>> 1) When we execute kexec() system call in first kernel, at that time it
>> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
>> (less than a sec) there.
>>
>> 2) When purgatory is executed then it re-calculates sha256 using same routines
>> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
>> (depending of size of binaries)?
>>
>> Why did not it take same time with O2 + D-cache enabled? I think, we should be
>> able to achieve same time in second case as well. What is missing?
I haven't benchmarked this, but:
util_lib/sha256.c contains calls out to memcpy().
In your case 1, this will use the glibc version. In case 2, it will use
the version implemented in purgatory/string.c, which is a byte-by-byte copy.
Thanks,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] kexec: Add --lite option
2015-12-07 13:16 ` James Morse
@ 2015-12-07 14:07 ` Pratyush Anand
-1 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-07 14:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi James,
Thanks for the reply.
On 07/12/2015:01:16:06 PM, James Morse wrote:
> Hi Pratyush,
>
> On 07/12/15 11:48, Pratyush Anand wrote:
> >> 1) When we execute kexec() system call in first kernel, at that time it
> >> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
> >> (less than a sec) there.
> >>
> >> 2) When purgatory is executed then it re-calculates sha256 using same routines
> >> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
> >> (depending of size of binaries)?
> >>
> >> Why did not it take same time with O2 + D-cache enabled? I think, we should be
> >> able to achieve same time in second case as well. What is missing?
>
> I haven't benchmarked this, but:
>
> util_lib/sha256.c contains calls out to memcpy().
> In your case 1, this will use the glibc version. In case 2, it will use
> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
>
Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
copy only few bytes (I think max 126 bytes). Most of the data will be processed
using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
think that this would be causing such a difference.
Could it be the case that I am not using perfect memory attributes while setting
up identity mapping and enabling D-cache. My implementation is here:
https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
~Pratyush
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
@ 2015-12-07 14:07 ` Pratyush Anand
0 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-07 14:07 UTC (permalink / raw)
To: James Morse
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel
Hi James,
Thanks for the reply.
On 07/12/2015:01:16:06 PM, James Morse wrote:
> Hi Pratyush,
>
> On 07/12/15 11:48, Pratyush Anand wrote:
> >> 1) When we execute kexec() system call in first kernel, at that time it
> >> calculates sha256 on all the binaries [1]. It take almost un-noticeable time
> >> (less than a sec) there.
> >>
> >> 2) When purgatory is executed then it re-calculates sha256 using same routines
> >> [2] on same binary data as that of case (1). But, now it takes 10-20 sec
> >> (depending of size of binaries)?
> >>
> >> Why did not it take same time with O2 + D-cache enabled? I think, we should be
> >> able to achieve same time in second case as well. What is missing?
>
> I haven't benchmarked this, but:
>
> util_lib/sha256.c contains calls out to memcpy().
> In your case 1, this will use the glibc version. In case 2, it will use
> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
>
Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
copy only few bytes (I think max 126 bytes). Most of the data will be processed
using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
think that this would be causing such a difference.
Could it be the case that I am not using perfect memory attributes while setting
up identity mapping and enabling D-cache. My implementation is here:
https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
~Pratyush
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH] kexec: Add --lite option
2015-12-07 14:07 ` Pratyush Anand
@ 2015-12-08 1:03 ` Scott Wood
-1 siblings, 0 replies; 32+ messages in thread
From: Scott Wood @ 2015-12-08 1:03 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2015-12-07 at 19:37 +0530, Pratyush Anand wrote:
> Hi James,
>
> Thanks for the reply.
>
> On 07/12/2015:01:16:06 PM, James Morse wrote:
> > Hi Pratyush,
> >
> > On 07/12/15 11:48, Pratyush Anand wrote:
> > > > 1) When we execute kexec() system call in first kernel, at that time
> > > > it
> > > > calculates sha256 on all the binaries [1]. It take almost un
> > > > -noticeable time
> > > > (less than a sec) there.
> > > >
> > > > 2) When purgatory is executed then it re-calculates sha256 using same
> > > > routines
> > > > [2] on same binary data as that of case (1). But, now it takes 10-20
> > > > sec
> > > > (depending of size of binaries)?
> > > >
> > > > Why did not it take same time with O2 + D-cache enabled? I think, we
> > > > should be
> > > > able to achieve same time in second case as well. What is missing?
> >
> > I haven't benchmarked this, but:
> >
> > util_lib/sha256.c contains calls out to memcpy().
> > In your case 1, this will use the glibc version. In case 2, it will use
> > the version implemented in purgatory/string.c, which is a byte-by-byte
> > copy.
> >
>
> Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update()
> will
> copy only few bytes (I think max 126 bytes). Most of the data will be
> processed
> using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do
> not
> think that this would be causing such a difference.
>
> Could it be the case that I am not using perfect memory attributes while
> setting
> up identity mapping and enabling D-cache. My implementation is here:
> https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0
> ddc519d7b68be82f
FWIW, purgatory is fast for me on PPC (sub-second), so between that (assuming
it's not due to some PPC-specific optimization) and the fact that you don't
see any improvement with cache, I'd guess there's something wrong with how
you're enabling caches.
-Scott
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
@ 2015-12-08 1:03 ` Scott Wood
0 siblings, 0 replies; 32+ messages in thread
From: Scott Wood @ 2015-12-08 1:03 UTC (permalink / raw)
To: Pratyush Anand, James Morse
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Dave Young, linux-arm-kernel
On Mon, 2015-12-07 at 19:37 +0530, Pratyush Anand wrote:
> Hi James,
>
> Thanks for the reply.
>
> On 07/12/2015:01:16:06 PM, James Morse wrote:
> > Hi Pratyush,
> >
> > On 07/12/15 11:48, Pratyush Anand wrote:
> > > > 1) When we execute kexec() system call in first kernel, at that time
> > > > it
> > > > calculates sha256 on all the binaries [1]. It take almost un
> > > > -noticeable time
> > > > (less than a sec) there.
> > > >
> > > > 2) When purgatory is executed then it re-calculates sha256 using same
> > > > routines
> > > > [2] on same binary data as that of case (1). But, now it takes 10-20
> > > > sec
> > > > (depending of size of binaries)?
> > > >
> > > > Why did not it take same time with O2 + D-cache enabled? I think, we
> > > > should be
> > > > able to achieve same time in second case as well. What is missing?
> >
> > I haven't benchmarked this, but:
> >
> > util_lib/sha256.c contains calls out to memcpy().
> > In your case 1, this will use the glibc version. In case 2, it will use
> > the version implemented in purgatory/string.c, which is a byte-by-byte
> > copy.
> >
>
> Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update()
> will
> copy only few bytes (I think max 126 bytes). Most of the data will be
> processed
> using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do
> not
> think that this would be causing such a difference.
>
> Could it be the case that I am not using perfect memory attributes while
> setting
> up identity mapping and enabling D-cache. My implementation is here:
> https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0
> ddc519d7b68be82f
FWIW, purgatory is fast for me on PPC (sub-second), so between that (assuming
it's not due to some PPC-specific optimization) and the fact that you don't
see any improvement with cache, I'd guess there's something wrong with how
you're enabling caches.
-Scott
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] kexec: Add --lite option
2015-12-07 14:07 ` Pratyush Anand
@ 2015-12-08 16:00 ` James Morse
-1 siblings, 0 replies; 32+ messages in thread
From: James Morse @ 2015-12-08 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Pratyush,
On 07/12/15 14:07, Pratyush Anand wrote:
> On 07/12/2015:01:16:06 PM, James Morse wrote:
>> I haven't benchmarked this, but:
>>
>> util_lib/sha256.c contains calls out to memcpy().
>> In your case 1, this will use the glibc version. In case 2, it will use
>> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
>>
>
> Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
> copy only few bytes (I think max 126 bytes). Most of the data will be processed
> using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
> think that this would be causing such a difference.
You're right, I benchmarked the two sha256.o files checksumming a 10MB
buffer - one takes 0.6s, the other 1.7s, we can probably expect a couple
of seconds to do this.
Is the sha256 really useful? Purgatory can't print out an error message,
if it fails...
> Could it be the case that I am not using perfect memory attributes while setting
> up identity mapping and enabling D-cache. My implementation is here:
> https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
I'm no expert, but that looks like you're setting it up as 'normal'
memory. You're missing some isb-s and tlbi-s: depending on how long the
changes to system state take, you may be using old memory-attributes or
page-tables. If you depend on a change to system state, (like turning
the mmu on), you need explicit synchronisation, see section 12.3.2 of
the 'Architecture Programmers Guide' (arm den0024a), and D7.1.2 of the
ARM ARM.
I haven't managed to get your kexec-tools branch to work with v10 of
Geoff's series. It looks like you save registers to the stack, which
give stale values once you turn the mmu off. You also do the opposite,
saving registers with the mmu off, then cleaning cache lines over the
top, corrupting the saved registers.
The page size of 64K is hard coded. Kexec-ing from a 4K kernel, to a 4K
kernel will work, but only if the hardware also supports 64K, this will
be surprising to debug.
Thanks,
James
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
@ 2015-12-08 16:00 ` James Morse
0 siblings, 0 replies; 32+ messages in thread
From: James Morse @ 2015-12-08 16:00 UTC (permalink / raw)
To: Pratyush Anand
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel
Hi Pratyush,
On 07/12/15 14:07, Pratyush Anand wrote:
> On 07/12/2015:01:16:06 PM, James Morse wrote:
>> I haven't benchmarked this, but:
>>
>> util_lib/sha256.c contains calls out to memcpy().
>> In your case 1, this will use the glibc version. In case 2, it will use
>> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
>>
>
> Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
> copy only few bytes (I think max 126 bytes). Most of the data will be processed
> using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
> think that this would be causing such a difference.
You're right, I benchmarked the two sha256.o files checksumming a 10MB
buffer - one takes 0.6s, the other 1.7s, we can probably expect a couple
of seconds to do this.
Is the sha256 really useful? Purgatory can't print out an error message,
if it fails...
> Could it be the case that I am not using perfect memory attributes while setting
> up identity mapping and enabling D-cache. My implementation is here:
> https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
I'm no expert, but that looks like you're setting it up as 'normal'
memory. You're missing some isb-s and tlbi-s: depending on how long the
changes to system state take, you may be using old memory-attributes or
page-tables. If you depend on a change to system state, (like turning
the mmu on), you need explicit synchronisation, see section 12.3.2 of
the 'Architecture Programmers Guide' (arm den0024a), and D7.1.2 of the
ARM ARM.
I haven't managed to get your kexec-tools branch to work with v10 of
Geoff's series. It looks like you save registers to the stack, which
give stale values once you turn the mmu off. You also do the opposite,
saving registers with the mmu off, then cleaning cache lines over the
top, corrupting the saved registers.
The page size of 64K is hard coded. Kexec-ing from a 4K kernel, to a 4K
kernel will work, but only if the hardware also supports 64K, this will
be surprising to debug.
Thanks,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH] kexec: Add --lite option
2015-12-08 16:00 ` James Morse
@ 2015-12-09 9:28 ` Pratyush Anand
-1 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-09 9:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi James,
On 08/12/2015:04:00:17 PM, James Morse wrote:
> Hi Pratyush,
>
> On 07/12/15 14:07, Pratyush Anand wrote:
> > On 07/12/2015:01:16:06 PM, James Morse wrote:
> >> I haven't benchmarked this, but:
> >>
> >> util_lib/sha256.c contains calls out to memcpy().
> >> In your case 1, this will use the glibc version. In case 2, it will use
> >> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
> >>
> >
> > Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
> > copy only few bytes (I think max 126 bytes). Most of the data will be processed
> > using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
> > think that this would be causing such a difference.
>
> You're right, I benchmarked the two sha256.o files checksumming a 10MB
> buffer - one takes 0.6s, the other 1.7s, we can probably expect a couple
> of seconds to do this.
>
> Is the sha256 really useful? Purgatory can't print out an error message,
> if it fails...
kdump needs the sha256 integrity checks. Please see previous reply from Dave,
Vivek and Eric in this thread.
Purgatory prints error message, in case sha256 fails. It prints expected and
calculated sha256 values. You must pass --port with proper value to see print
messages. Geoff has been able to see purgatory debug messages on foundation
model only with --port, however I need below patch and pass --port-lsr as well
in order to print all the characters properly.
https://github.com/pratyushanand/kexec-tools/commit/ab30f4015189b177dd2e78980f5b7e47c2d22fe4
So, on a system having pl011 base address 0xe1010000, I pass --port=0xe1010000
--port-lsr=0xe1010018,0x80 to the kexec command.
>
>
> > Could it be the case that I am not using perfect memory attributes while setting
> > up identity mapping and enabling D-cache. My implementation is here:
> > https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
>
First of all, thanks a lot for taking out your time to review it :-)
> I'm no expert, but that looks like you're setting it up as 'normal'
Me too not an expert.
Shouldn't it be normal type memory? I think, I will need to define only UART
area as device type (currently it is not defined, and so I am not able to use
print message while mmu is enabled).
> memory. You're missing some isb-s and tlbi-s: depending on how long the
> changes to system state take, you may be using old memory-attributes or
> page-tables. If you depend on a change to system state, (like turning
> the mmu on), you need explicit synchronisation, see section 12.3.2 of
> the 'Architecture Programmers Guide' (arm den0024a), and D7.1.2 of the
> ARM ARM.
I will go through these docs and kernel arch/arm64/kernel/head.S and will
rewrite the cache implementation.
>
> I haven't managed to get your kexec-tools branch to work with v10 of
May be you can try master branch. It is almost same as that of Geoff's.
Additionally, it has support to "wait for transmit completion before next
character transmission".
> Geoff's series. It looks like you save registers to the stack, which
> give stale values once you turn the mmu off. You also do the opposite,
> saving registers with the mmu off, then cleaning cache lines over the
> top, corrupting the saved registers.
>
> The page size of 64K is hard coded. Kexec-ing from a 4K kernel, to a 4K
> kernel will work, but only if the hardware also supports 64K, this will
> be surprising to debug.
OK, I will take care in the re-implementation.
Thanks
~Pratyush
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
@ 2015-12-09 9:28 ` Pratyush Anand
0 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2015-12-09 9:28 UTC (permalink / raw)
To: James Morse
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel
Hi James,
On 08/12/2015:04:00:17 PM, James Morse wrote:
> Hi Pratyush,
>
> On 07/12/15 14:07, Pratyush Anand wrote:
> > On 07/12/2015:01:16:06 PM, James Morse wrote:
> >> I haven't benchmarked this, but:
> >>
> >> util_lib/sha256.c contains calls out to memcpy().
> >> In your case 1, this will use the glibc version. In case 2, it will use
> >> the version implemented in purgatory/string.c, which is a byte-by-byte copy.
> >>
> >
> > Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update() will
> > copy only few bytes (I think max 126 bytes). Most of the data will be processed
> > using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do not
> > think that this would be causing such a difference.
>
> You're right, I benchmarked the two sha256.o files checksumming a 10MB
> buffer - one takes 0.6s, the other 1.7s, we can probably expect a couple
> of seconds to do this.
>
> Is the sha256 really useful? Purgatory can't print out an error message,
> if it fails...
kdump needs the sha256 integrity checks. Please see previous reply from Dave,
Vivek and Eric in this thread.
Purgatory prints error message, in case sha256 fails. It prints expected and
calculated sha256 values. You must pass --port with proper value to see print
messages. Geoff has been able to see purgatory debug messages on foundation
model only with --port, however I need below patch and pass --port-lsr as well
in order to print all the characters properly.
https://github.com/pratyushanand/kexec-tools/commit/ab30f4015189b177dd2e78980f5b7e47c2d22fe4
So, on a system having pl011 base address 0xe1010000, I pass --port=0xe1010000
--port-lsr=0xe1010018,0x80 to the kexec command.
>
>
> > Could it be the case that I am not using perfect memory attributes while setting
> > up identity mapping and enabling D-cache. My implementation is here:
> > https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0ddc519d7b68be82f
>
First of all, thanks a lot for taking out your time to review it :-)
> I'm no expert, but that looks like you're setting it up as 'normal'
Me too not an expert.
Shouldn't it be normal type memory? I think, I will need to define only UART
area as device type (currently it is not defined, and so I am not able to use
print message while mmu is enabled).
> memory. You're missing some isb-s and tlbi-s: depending on how long the
> changes to system state take, you may be using old memory-attributes or
> page-tables. If you depend on a change to system state, (like turning
> the mmu on), you need explicit synchronisation, see section 12.3.2 of
> the 'Architecture Programmers Guide' (arm den0024a), and D7.1.2 of the
> ARM ARM.
I will go through these docs and kernel arch/arm64/kernel/head.S and will
rewrite the cache implementation.
>
> I haven't managed to get your kexec-tools branch to work with v10 of
May be you can try master branch. It is almost same as that of Geoff's.
Additionally, it has support to "wait for transmit completion before next
character transmission".
> Geoff's series. It looks like you save registers to the stack, which
> give stale values once you turn the mmu off. You also do the opposite,
> saving registers with the mmu off, then cleaning cache lines over the
> top, corrupting the saved registers.
>
> The page size of 64K is hard coded. Kexec-ing from a 4K kernel, to a 4K
> kernel will work, but only if the hardware also supports 64K, this will
> be surprising to debug.
OK, I will take care in the re-implementation.
Thanks
~Pratyush
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH] kexec: Add --lite option
2015-12-09 9:28 ` Pratyush Anand
@ 2016-01-11 12:46 ` Pratyush Anand
-1 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2016-01-11 12:46 UTC (permalink / raw)
To: linux-arm-kernel
+Fu
Hi James,
> On 08/12/2015:04:00:17 PM, James Morse wrote:
> > Hi Pratyush,
> > I haven't managed to get your kexec-tools branch to work with v10 of
Thanks for all your feedback. It helped to stabilize the code better. I took
all your suggestions and also did few other modifications [1]. Now, purgatory
does SHA verifications on mustang and seattle within a second. I think this
would be helpful in handling few of the kdump issues with watchdog. May be you
can give a try to the code in branch purgatory-enable-dcache of my tree. Any
feedback would be welcome.
~Pratyush
[1] https://github.com/pratyushanand/kexec-tools/commit/5679d4baaa5e644f8302982c6f468214ed3d3f3d
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
@ 2016-01-11 12:46 ` Pratyush Anand
0 siblings, 0 replies; 32+ messages in thread
From: Pratyush Anand @ 2016-01-11 12:46 UTC (permalink / raw)
To: James Morse
Cc: Geoff Levand, kexec, Simon Horman, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel, Wei Fu
+Fu
Hi James,
> On 08/12/2015:04:00:17 PM, James Morse wrote:
> > Hi Pratyush,
> > I haven't managed to get your kexec-tools branch to work with v10 of
Thanks for all your feedback. It helped to stabilize the code better. I took
all your suggestions and also did few other modifications [1]. Now, purgatory
does SHA verifications on mustang and seattle within a second. I think this
would be helpful in handling few of the kdump issues with watchdog. May be you
can give a try to the code in branch purgatory-enable-dcache of my tree. Any
feedback would be welcome.
~Pratyush
[1] https://github.com/pratyushanand/kexec-tools/commit/5679d4baaa5e644f8302982c6f468214ed3d3f3d
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] kexec: Add --lite option
2016-01-11 12:46 ` Pratyush Anand
@ 2016-01-12 1:06 ` Simon Horman
-1 siblings, 0 replies; 32+ messages in thread
From: Simon Horman @ 2016-01-12 1:06 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 06:16:38PM +0530, Pratyush Anand wrote:
> +Fu
>
> Hi James,
>
> > On 08/12/2015:04:00:17 PM, James Morse wrote:
> > > Hi Pratyush,
>
> > > I haven't managed to get your kexec-tools branch to work with v10 of
>
> Thanks for all your feedback. It helped to stabilize the code better. I took
> all your suggestions and also did few other modifications [1]. Now, purgatory
> does SHA verifications on mustang and seattle within a second. I think this
> would be helpful in handling few of the kdump issues with watchdog. May be you
> can give a try to the code in branch purgatory-enable-dcache of my tree. Any
> feedback would be welcome.
Please post the patches here for review.
Thanks
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
@ 2016-01-12 1:06 ` Simon Horman
0 siblings, 0 replies; 32+ messages in thread
From: Simon Horman @ 2016-01-12 1:06 UTC (permalink / raw)
To: Pratyush Anand
Cc: Geoff Levand, kexec, James Morse, Vivek Goyal, Petitboot,
Scott Wood, Dave Young, linux-arm-kernel, Wei Fu
On Mon, Jan 11, 2016 at 06:16:38PM +0530, Pratyush Anand wrote:
> +Fu
>
> Hi James,
>
> > On 08/12/2015:04:00:17 PM, James Morse wrote:
> > > Hi Pratyush,
>
> > > I haven't managed to get your kexec-tools branch to work with v10 of
>
> Thanks for all your feedback. It helped to stabilize the code better. I took
> all your suggestions and also did few other modifications [1]. Now, purgatory
> does SHA verifications on mustang and seattle within a second. I think this
> would be helpful in handling few of the kdump issues with watchdog. May be you
> can give a try to the code in branch purgatory-enable-dcache of my tree. Any
> feedback would be welcome.
Please post the patches here for review.
Thanks
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-22 3:17 ` Dave Young
2015-10-22 12:50 ` Vivek Goyal
@ 2015-10-22 18:57 ` Geoff Levand
2015-10-22 19:04 ` Vivek Goyal
` (2 more replies)
1 sibling, 3 replies; 32+ messages in thread
From: Geoff Levand @ 2015-10-22 18:57 UTC (permalink / raw)
To: Dave Young; +Cc: panand, Simon Horman, kexec, Petitboot, vgoyal
Hi Dave,
On Thu, 2015-10-22 at 11:17 +0800, Dave Young wrote:
> On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > Add a new option --lite to kexec that allows for a fast reboot
> > by avoiding the purgatory integrity checks. This option is
> > intended for use by kexec based bootloaders that load a new
> > image and then immediately transfer control to it.
>
> I think Vivek was rejecting this --lite since kdump need the purgatory
> integrity checks. Ccing him.
As stated, this is not intended for use by kdump.
This is an optional feature. It does not remove the integrity
checks, but provides the user a way to bypass them if they so
desire.
> > It was reported that on some systems where purgatory is running
> > without caches enabled the sha256 calculations would take several
> > minutes. For bootloaders that just load a new image and
> > immediately jump into it the loss of the integrity check is worth
> > the increase in boot speed. Please consider.
>
> Pratyush reported the arm64 issue, he sent a patch to fix it with
> enabling cache for purgatory. I think the patch can fix the problem.
> Why not fix it? The fix is simple enough and it does not introduce
> complicate logic.
This patch also is simple, and is architecture independent. I see this
feature as an improvement to kexec, not necessarily as a fix for that
problem.
-Geoff
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] kexec: Add --lite option
2015-10-22 18:57 ` Geoff Levand
@ 2015-10-22 19:04 ` Vivek Goyal
2015-10-23 9:46 ` Dave Young
2015-10-23 19:02 ` Eric W. Biederman
2 siblings, 0 replies; 32+ messages in thread
From: Vivek Goyal @ 2015-10-22 19:04 UTC (permalink / raw)
To: Geoff Levand; +Cc: panand, kexec, Simon Horman, Dave Young, Petitboot
On Thu, Oct 22, 2015 at 11:57:20AM -0700, Geoff Levand wrote:
> Hi Dave,
>
> On Thu, 2015-10-22 at 11:17 +0800, Dave Young wrote:
> > On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > > Add a new option --lite to kexec that allows for a fast reboot
> > > by avoiding the purgatory integrity checks. This option is
> > > intended for use by kexec based bootloaders that load a new
> > > image and then immediately transfer control to it.
> >
> > I think Vivek was rejecting this --lite since kdump need the purgatory
> > integrity checks. Ccing him.
>
> As stated, this is not intended for use by kdump.
>
> This is an optional feature. It does not remove the integrity
> checks, but provides the user a way to bypass them if they so
> desire.
Why would somebody like to bypass these checks?
>
> > > It was reported that on some systems where purgatory is running
> > > without caches enabled the sha256 calculations would take several
> > > minutes. For bootloaders that just load a new image and
> > > immediately jump into it the loss of the integrity check is worth
> > > the increase in boot speed. Please consider.
> >
> > Pratyush reported the arm64 issue, he sent a patch to fix it with
> > enabling cache for purgatory. I think the patch can fix the problem.
> > Why not fix it? The fix is simple enough and it does not introduce
> > complicate logic.
>
> This patch also is simple, and is architecture independent. I see this
> feature as an improvement to kexec, not necessarily as a fix for that
> problem.
I am not sure why does somebody care if segments are being checked
during transition or not?
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-22 18:57 ` Geoff Levand
2015-10-22 19:04 ` Vivek Goyal
@ 2015-10-23 9:46 ` Dave Young
2015-10-23 18:49 ` Geoff Levand
2015-10-23 19:02 ` Eric W. Biederman
2 siblings, 1 reply; 32+ messages in thread
From: Dave Young @ 2015-10-23 9:46 UTC (permalink / raw)
To: Geoff Levand; +Cc: panand, Simon Horman, kexec, Petitboot, vgoyal
Hi, Geoff
On 10/22/15 at 11:57am, Geoff Levand wrote:
> Hi Dave,
>
> On Thu, 2015-10-22 at 11:17 +0800, Dave Young wrote:
> > On 10/21/15 at 04:12pm, Geoff Levand wrote:
> > > Add a new option --lite to kexec that allows for a fast reboot
> > > by avoiding the purgatory integrity checks. This option is
> > > intended for use by kexec based bootloaders that load a new
> > > image and then immediately transfer control to it.
> >
> > I think Vivek was rejecting this --lite since kdump need the purgatory
> > integrity checks. Ccing him.
>
> As stated, this is not intended for use by kdump.
>
> This is an optional feature. It does not remove the integrity
> checks, but provides the user a way to bypass them if they so
> desire.
Problem is why they so desire to skip purgatory? what is the background?
If the only problem is the performace issue without cache enabled then
I think it is not a strong one. We have a design to verify the image and it
works why can't we maintain it and fix the issue instead of introducing
the --lite?
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-23 9:46 ` Dave Young
@ 2015-10-23 18:49 ` Geoff Levand
0 siblings, 0 replies; 32+ messages in thread
From: Geoff Levand @ 2015-10-23 18:49 UTC (permalink / raw)
To: Dave Young; +Cc: panand, Simon Horman, kexec, Petitboot, vgoyal
Hi Dave,
On Fri, 2015-10-23 at 17:46 +0800, Dave Young wrote:
> On 10/22/15 at 11:57am, Geoff Levand wrote:
> > As stated, this is not intended for use by kdump.
> >
> > This is an optional feature. It does not remove the integrity
> > checks, but provides the user a way to bypass them if they so
> > desire.
>
> Problem is why they so desire to skip purgatory? what is the background?
This doesn't remove or skip purgatory. Purgatory is still used.
What it does do is skip the digest calculations that are done
when an image is loaded (kexec --load), and it skips the digest
calculations and comparison when the new image is run
(kexec --exec).
The digest check is great for kdump, where the crash kernel is
loaded, and some time later a possibly unstable system tries to
do a kexec and we want to assure the integrity of the new image.
Kexec based bootloaders are very different. They are running
in a stable state. They load a new image and immediately
transfer control to that new image. Because the system is in a
stable state, and very little is done between the time the image
is loaded and the time it is entered, there is little reason to
do an integrity check, and by avoiding it we can speed up the
boot process.
Faster boot (and re-boot) time is important to users, vendors,
highly available systems, they all want it.
-Geoff
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] kexec: Add --lite option
2015-10-22 18:57 ` Geoff Levand
2015-10-22 19:04 ` Vivek Goyal
2015-10-23 9:46 ` Dave Young
@ 2015-10-23 19:02 ` Eric W. Biederman
2 siblings, 0 replies; 32+ messages in thread
From: Eric W. Biederman @ 2015-10-23 19:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: panand, kexec, Simon Horman, Petitboot, Dave Young, vgoyal
Geoff Levand <geoff@infradead.org> writes:
>> > It was reported that on some systems where purgatory is running
>> > without caches enabled the sha256 calculations would take several
>> > minutes. For bootloaders that just load a new image and
>> > immediately jump into it the loss of the integrity check is worth
>> > the increase in boot speed. Please consider.
>>
>> Pratyush reported the arm64 issue, he sent a patch to fix it with
>> enabling cache for purgatory. I think the patch can fix the problem.
>> Why not fix it? The fix is simple enough and it does not introduce
>> complicate logic.
>
> This patch also is simple, and is architecture independent. I see this
> feature as an improvement to kexec, not necessarily as a fix for that
> problem.
Disabling image verification is not an improvement, all it does is
allow for a nasty form of heisenbug.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2] kexec: Add --no-checks option
2015-10-21 23:12 [PATCH] kexec: Add --lite option Geoff Levand
2015-10-22 0:02 ` Jeremy Kerr
2015-10-22 3:17 ` Dave Young
@ 2018-04-11 18:30 ` Geoff Levand
2018-04-19 8:38 ` Simon Horman
2 siblings, 1 reply; 32+ messages in thread
From: Geoff Levand @ 2018-04-11 18:30 UTC (permalink / raw)
To: Simon Horman; +Cc: James Morse, Kostiantyn Iarmak, kexec, Petitboot
Add a new option --no-checks to kexec that allows for a fast
reboot by avoiding the purgatory integrity checks. This option is
intended for use by kexec based bootloaders that load a new
image and then immediately transfer control to it.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
Hi Simon,
On 10/21/2015 04:12 PM, Geoff Levand wrote:
> Hi Simon,
>
> It was reported that on some systems where purgatory is running
> without caches enabled the sha256 calculations would take several
> minutes. For bootloaders that just load a new image and
> immediately jump into it the loss of the integrity check is worth
> the increase in boot speed. Please consider.
There seems to be continued interest in faster kexec re-boot times
on arm64 systems so I rebased my old patch and renamed the
option from '--lite' to '--no-checks'. Please consider.
-Geoff
kexec/kexec.8 | 3 +++
kexec/kexec.c | 19 +++++++++++++++++--
kexec/kexec.h | 6 +++++-
purgatory/purgatory.c | 3 ++-
4 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/kexec/kexec.8 b/kexec/kexec.8
index fb8a4c9..2fafaaa 100644
--- a/kexec/kexec.8
+++ b/kexec/kexec.8
@@ -132,6 +132,9 @@ in one call.
Open a help file for
.BR kexec .
.TP
+.B \-i\ (\-\-no-checks)
+Fast reboot, no memory integrity checks.
+.TP
.BI \-l\ (\-\-load) \ kernel
Load the specified
.I kernel
diff --git a/kexec/kexec.c b/kexec/kexec.c
index 313d9fe..a512047 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -647,6 +647,15 @@ static void update_purgatory(struct kexec_info *info)
return;
}
arch_update_purgatory(info);
+
+ if (info->skip_checks) {
+ unsigned int tmp = 1;
+
+ elf_rel_set_symbol(&info->rhdr, "skip_checks", &tmp,
+ sizeof(tmp));
+ return;
+ }
+
memset(region, 0, sizeof(region));
sha256_starts(&ctx);
/* Compute a hash of the loaded kernel */
@@ -686,7 +695,7 @@ static void update_purgatory(struct kexec_info *info)
* Load the new kernel
*/
static int my_load(const char *type, int fileind, int argc, char **argv,
- unsigned long kexec_flags, void *entry)
+ unsigned long kexec_flags, int skip_checks, void *entry)
{
char *kernel;
char *kernel_buf;
@@ -699,6 +708,7 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
memset(&info, 0, sizeof(info));
info.kexec_flags = kexec_flags;
+ info.skip_checks = skip_checks;
result = 0;
if (argc - fileind <= 0) {
@@ -980,6 +990,7 @@ void usage(void)
" -v, --version Print the version of kexec.\n"
" -f, --force Force an immediate kexec,\n"
" don't call shutdown.\n"
+ " -i, --no-checks Fast reboot, no memory integrity checks.\n"
" -x, --no-ifdown Don't bring down network interfaces.\n"
" -y, --no-sync Don't sync filesystems before kexec.\n"
" -l, --load Load the new kernel into the\n"
@@ -1250,6 +1261,7 @@ int main(int argc, char *argv[])
int do_reuse_initrd = 0;
int do_kexec_file_syscall = 0;
int do_kexec_fallback = 0;
+ int skip_checks = 0;
int do_status = 0;
void *entry = 0;
char *type = 0;
@@ -1385,6 +1397,9 @@ int main(int argc, char *argv[])
do_kexec_file_syscall = 1;
do_kexec_fallback = 1;
break;
+ case OPT_NOCHECKS:
+ skip_checks = 1;
+ break;
case OPT_STATUS:
do_status = 1;
break;
@@ -1519,7 +1534,7 @@ int main(int argc, char *argv[])
}
if (!do_kexec_file_syscall)
result = my_load(type, fileind, argc, argv,
- kexec_flags, entry);
+ kexec_flags, skip_checks, entry);
}
/* Don't shutdown unless there is something to reboot to! */
if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded(KEXEC_LOADED_PATH)) {
diff --git a/kexec/kexec.h b/kexec/kexec.h
index d445fbe..a97b9ce 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -166,6 +166,8 @@ struct kexec_info {
int initrd_fd;
char *command_line;
int command_line_len;
+
+ int skip_checks;
};
struct arch_map_entry {
@@ -211,6 +213,7 @@ extern int file_types;
#define OPT_VERSION 'v'
#define OPT_DEBUG 'd'
#define OPT_FORCE 'f'
+#define OPT_NOCHECKS 'i'
#define OPT_NOIFDOWN 'x'
#define OPT_NOSYNC 'y'
#define OPT_EXEC 'e'
@@ -234,6 +237,7 @@ extern int file_types;
{ "help", 0, 0, OPT_HELP }, \
{ "version", 0, 0, OPT_VERSION }, \
{ "force", 0, 0, OPT_FORCE }, \
+ { "no-checks", 0, 0, OPT_NOCHECKS }, \
{ "no-ifdown", 0, 0, OPT_NOIFDOWN }, \
{ "no-sync", 0, 0, OPT_NOSYNC }, \
{ "load", 0, 0, OPT_LOAD }, \
@@ -254,7 +258,7 @@ extern int file_types;
{ "status", 0, 0, OPT_STATUS }, \
{ "print-ckr-size", 0, 0, OPT_PRINT_CKR_SIZE }, \
-#define KEXEC_OPT_STR "h?vdfxyluet:pscaS"
+#define KEXEC_OPT_STR "h?vdfixyluet:pscaS"
extern void dbgprint_mem_range(const char *prefix, struct memory_range *mr, int nr_mr);
extern void die(const char *fmt, ...)
diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
index 3bbcc09..73930aa 100644
--- a/purgatory/purgatory.c
+++ b/purgatory/purgatory.c
@@ -8,6 +8,7 @@
struct sha256_region sha256_regions[SHA256_REGIONS] = {};
sha256_digest_t sha256_digest = { };
+int skip_checks = 0;
int verify_sha256_digest(void)
{
@@ -43,7 +44,7 @@ void purgatory(void)
{
printf("I'm in purgatory\n");
setup_arch();
- if (verify_sha256_digest()) {
+ if (!skip_checks && verify_sha256_digest()) {
for(;;) {
/* loop forever */
}
--
2.14.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2] kexec: Add --no-checks option
2018-04-11 18:30 ` [PATCH v2] kexec: Add --no-checks option Geoff Levand
@ 2018-04-19 8:38 ` Simon Horman
0 siblings, 0 replies; 32+ messages in thread
From: Simon Horman @ 2018-04-19 8:38 UTC (permalink / raw)
To: Geoff Levand; +Cc: James Morse, Kostiantyn Iarmak, kexec, Petitboot
On Wed, Apr 11, 2018 at 11:30:48AM -0700, Geoff Levand wrote:
> Add a new option --no-checks to kexec that allows for a fast
> reboot by avoiding the purgatory integrity checks. This option is
> intended for use by kexec based bootloaders that load a new
> image and then immediately transfer control to it.
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi Simon,
>
> On 10/21/2015 04:12 PM, Geoff Levand wrote:
> > Hi Simon,
> >
> > It was reported that on some systems where purgatory is running
> > without caches enabled the sha256 calculations would take several
> > minutes. For bootloaders that just load a new image and
> > immediately jump into it the loss of the integrity check is worth
> > the increase in boot speed. Please consider.
>
> There seems to be continued interest in faster kexec re-boot times
> on arm64 systems so I rebased my old patch and renamed the
> option from '--lite' to '--no-checks'. Please consider.
Thanks, applied.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 32+ messages in thread