Re: [PATCH 3/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification
On Tue, Feb 15, 2022 at 08:39:40PM +0100, Michal Suchanek wrote:
> commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> adds support for KEXEC_SIG verification with keys from platform keyring
> but the built-in keys and secondary keyring are not used.
>
> Add support for the built-in keys and secondary keyring as x86 does.
>
> Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> Cc: Philipp Rudo
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek
Reviewed-by: "Lee, Chun-Yi"
> ---
> arch/s390/kernel/machine_kexec_file.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/s390/kernel/machine_kexec_file.c
> b/arch/s390/kernel/machine_kexec_file.c
> index 8f43575a4dd3..fc6d5f58debe 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long
> kernel_len)
> const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
> struct module_signature *ms;
> unsigned long sig_len;
> + int ret;
>
> /* Skip signature verification when not secure IPLed. */
> if (!ipl_secure_flag)
> @@ -65,11 +66,18 @@ int s390_verify_sig(const char *kernel, unsigned long
> kernel_len)
> return -EBADMSG;
> }
>
> - return verify_pkcs7_signature(kernel, kernel_len,
> - kernel + kernel_len, sig_len,
> - VERIFY_USE_PLATFORM_KEYRING,
> - VERIFYING_MODULE_SIGNATURE,
> - NULL, NULL);
> + ret = verify_pkcs7_signature(kernel, kernel_len,
> + kernel + kernel_len, sig_len,
> + VERIFY_USE_SECONDARY_KEYRING,
> + VERIFYING_MODULE_SIGNATURE,
> + NULL, NULL);
> + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
> + ret = verify_pkcs7_signature(kernel, kernel_len,
> + kernel + kernel_len, sig_len,
> + VERIFY_USE_PLATFORM_KEYRING,
> + VERIFYING_MODULE_SIGNATURE,
> + NULL, NULL);
> + return ret;
> }
> #endif /* CONFIG_KEXEC_SIG */
>
> --
> 2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/4] kexec, KEYS, arm64: Make use of platform keyring for signature verification
On Tue, Feb 15, 2022 at 08:39:39PM +0100, Michal Suchanek wrote:
> commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature
> verify")
> adds platform keyring support on x86 kexec but not arm64.
>
> Add platform keyring support on arm64 as well.
>
> Fixes: 278311e417be ("kexec, KEYS: Make use of platform keyring for signature
> verify")
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek
Reviewed-by: "Lee, Chun-Yi"
> ---
> arch/arm64/kernel/kexec_image.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 1fbf2ee7c005..3dee7b2d8336 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,9 +133,17 @@ static void *image_load(struct kimage *image,
> #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
> static int image_verify_sig(const char *kernel, unsigned long kernel_len)
> {
> - return verify_pefile_signature(kernel, kernel_len,
> -VERIFY_USE_SECONDARY_KEYRING,
> -VERIFYING_KEXEC_PE_SIGNATURE);
> + int ret;
> +
> + ret = verify_pefile_signature(kernel, kernel_len,
> + VERIFY_USE_SECONDARY_KEYRING,
> + VERIFYING_KEXEC_PE_SIGNATURE);
> + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
> + ret = verify_pefile_signature(kernel, kernel_len,
> + VERIFY_USE_PLATFORM_KEYRING,
> + VERIFYING_KEXEC_PE_SIGNATURE);
> + }
> + return ret;
> }
> #endif
>
> --
> 2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot
On Tue, Feb 15, 2022 at 08:39:38PM +0100, Michal Suchanek wrote:
> commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added
> to dynamically")
> split of .system_keyring into .builtin_trusted_keys and
> .secondary_trusted_keys broke kexec, thereby preventing kernels signed by
> keys which are now in the secondary keyring from being kexec'd.
>
> Fix this by passing VERIFY_USE_SECONDARY_KEYRING to
> verify_pefile_signature().
>
> Cherry-picked from
> commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the
> secondary keyring to boot")
>
> Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification
> support")
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek
Reviewed-by: "Lee, Chun-Yi"
> ---
> arch/arm64/kernel/kexec_image.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 9ec34690e255..1fbf2ee7c005 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
> #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
> static int image_verify_sig(const char *kernel, unsigned long kernel_len)
> {
> - return verify_pefile_signature(kernel, kernel_len, NULL,
> + return verify_pefile_signature(kernel, kernel_len,
> +VERIFY_USE_SECONDARY_KEYRING,
> VERIFYING_KEXEC_PE_SIGNATURE);
> }
> #endif
> --
> 2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map
On Mon, Apr 16, 2018 at 06:35:22PM -0600, Randy Wright wrote: > On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote: > > Hi Randy, > > ... > > Randy, do you want to try Dave's kexec patch on your environment? Please > > remove > > my patch first. > > > > Thanks a lot! > > Joey Lee > > Hi Joey, > > I tried Dave's patch to kexec-bzimage64.c on my build of the SuSE > 4.12.14-15 kernel. I ran the same test as I did with your patch: I > verified the early_ioremap.c warnings occurred with a crash triggered > from a kexec boot of the unmodified kernel. Then I applied the patch to > kexec-bzimage64.c, rebuilt, re-ran the test to crash from the kexec'ed > kernel, and verified the warnings are no longer seen. > Thanks for your help! Looks that Dave's kexec patch works to prevent the warning message. > I'm out of time today, but I will plan to run the same test tomorrow on > a build of the SuSE 4.4.120-94.17 kernel, on which I had also reported > the original bug. > Both kexec and efi sides will be applied patches. Thanks a lot! Joey Lee ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map
Hi Randy, On Mon, Apr 16, 2018 at 11:09:04AM +0800, Dave Young wrote: > On 04/16/18 at 10:57am, Dave Young wrote: > > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > > When using kdump, SOMETIMES the "size not consistent" warning message > > > shows up when the crash kernel boots with early_ioremap_debug parameter: > > > > > > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 > > > early_iounmap+0x4f/0x12c() > > > early_iounmap(ff200180, 0118) [0] size not consistent 0120 > > > [...snip] > > > > Good catch. The kexec code need to be fixed to use a separate buffer so > > avoid the alignment like what kexec-tools did. I can submit a fix for > > that. > > Can you try below code, see if it works? > Randy, do you want to try Dave's kexec patch on your environment? Please remove my patch first. Thanks a lot! Joey Lee > > diff --git a/arch/x86/kernel/kexec-bzimage64.c > b/arch/x86/kernel/kexec-bzimage64.c > index 3182908b7e6c..eaee37c54b7b 100644 > --- a/arch/x86/kernel/kexec-bzimage64.c > +++ b/arch/x86/kernel/kexec-bzimage64.c > @@ -398,11 +398,10 @@ static void *bzImage64_load(struct kimage *image, char > *kernel, >* little bit simple >*/ > efi_map_sz = efi_get_runtime_map_size(); > - efi_map_sz = ALIGN(efi_map_sz, 16); > params_cmdline_sz = sizeof(struct boot_params) + cmdline_len + > MAX_ELFCOREHDR_STR_LEN; > params_cmdline_sz = ALIGN(params_cmdline_sz, 16); > - kbuf.bufsz = params_cmdline_sz + efi_map_sz + > + kbuf.bufsz = params_cmdline_sz + ALIGN(efi_map_sz, 16)+ > sizeof(struct setup_data) + > sizeof(struct efi_setup_data); > > @@ -410,7 +409,7 @@ static void *bzImage64_load(struct kimage *image, char > *kernel, > if (!params) > return ERR_PTR(-ENOMEM); > efi_map_offset = params_cmdline_sz; > - efi_setup_data_offset = efi_map_offset + efi_map_sz; > + efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16); > > /* Copy setup header onto bootparams. Documentation/x86/boot.txt */ > setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset; ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map
On Mon, Apr 16, 2018 at 10:57:34AM +0800, Dave Young wrote: > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > When using kdump, SOMETIMES the "size not consistent" warning message > > shows up when the crash kernel boots with early_ioremap_debug parameter: > > > > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 > > early_iounmap+0x4f/0x12c() > > early_iounmap(ff200180, 0118) [0] size not consistent 0120 > > > > The root cause is that the unmapping size of memory map doesn't > > match with the original size when mapping: > > > > in __efi_memmap_init() > > map.map = early_memremap(phys_map, data->size); > > > > in efi_memmap_unmap() > > size = efi.memmap.desc_size * efi.memmap.nr_map; > > early_memunmap(efi.memmap.map, size); > > > > But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder > > of size was discarded when calculating the nr_map: > > map.nr_map = data->size / data->desc_size; > > > > When the original size of memory map region does not equal to the > > result of multiplication. The "size not consistent" warning > > will be triggered. > > > > This issue sometimes was hit by kdump because kexec set the efi map > > size to align with 16 when loading crash kernel image: > > > > in bzImage64_load() > > efi_map_sz = efi_get_runtime_map_size(); > > efi_map_sz = ALIGN(efi_map_sz, 16); > > > > This patch changes the logic in the unmapping function. Using the > > end address of map to calcuate original size. > > > > Thank Randy Wright for his report and testing. And also thank > > Takashi Iwai for his help to trace issue. > > Good catch. The kexec code need to be fixed to use a separate buffer so > avoid the alignment like what kexec-tools did. I can submit a fix for > that. > Thanks! > But this issue could be a potential issue even if kexec get fixed so it > looks worth a fix in efi code as well. How about mapping only nr_maps > *desc_size in __efi_memmap_init? It looks easier to understand. > Takashi has another patch as you said. Finally I sent this patch because it's smaller. Thanks a lot! Joey Lee ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed
On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote: > On Fri, 15 Jul 2016 07:57:22 +0800 > joeyli wrote: > > > Hi Vivek > > > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote: > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote: > > > > This patch adds a new "--fallback-kexec" option to give a chance to > > > > fallback to old kexec syscall when file based kexec syscall operation > > > > failed. > > > > > > I think caller should switch to using different interface if need be. But > > > I don't see much point in providing an option for this in kexec-tools. > > > > > > Vivek > > > > > > > OK~ Understood! > > > > Thanks for Baoquan's and your opinion for this patch. > > Is there some sort of diagnostics, so a calling script can determine > whether kexec failed, because there's no suppor for kexec_file_load(2) > or for a different reason? > > Thanks, > Petr T The calling script needs to use "-s" option to access file based kexec, then check the result and call kexec without -s to access old kexec syscall. With this patch is just more convenience. Thanks a lot! Joey Lee ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed
Hi Vivek
On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote:
> On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote:
> > This patch adds a new "--fallback-kexec" option to give a chance to
> > fallback to old kexec syscall when file based kexec syscall operation
> > failed.
>
> I think caller should switch to using different interface if need be. But
> I don't see much point in providing an option for this in kexec-tools.
>
> Vivek
>
OK~ Understood!
Thanks for Baoquan's and your opinion for this patch.
Joey Lee
> >
> > This option works with --kexec-file-syscall to provide more flexible
> > way to adapt to different kernels that those kernels built with
> > different kexec syscall config or have different verification policy.
> >
> > Cc: Simon Horman
> > Cc: Petr Tesarik
> > Cc: Vivek Goyal
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > kexec/kexec.c | 13 +
> > kexec/kexec.h | 4 +++-
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/kexec/kexec.c b/kexec/kexec.c
> > index 500e5a9..e05b43f 100644
> > --- a/kexec/kexec.c
> > +++ b/kexec/kexec.c
> > @@ -969,6 +969,7 @@ void usage(void)
> >" preserve context)\n"
> >" to original kernel.\n"
> >" -s, --kexec-file-syscall Use file based syscall for kexec
> > operation\n"
> > + " --fallback-kexec Fallback to old kexec when file based
> > syscall failed\n"
> >" -d, --debug Enable debugging to help spot a
> > failure.\n"
> >"\n"
> >"Supported kernel file types and options: \n");
> > @@ -1204,6 +1205,7 @@ int main(int argc, char *argv[])
> > int do_unload = 0;
> > int do_reuse_initrd = 0;
> > int do_kexec_file_syscall = 0;
> > + int do_fallback_kexec_syscall = 0;
> > void *entry = 0;
> > char *type = 0;
> > char *endptr;
> > @@ -1226,9 +1228,13 @@ int main(int argc, char *argv[])
> > case OPT_KEXEC_FILE_SYSCALL:
> > do_kexec_file_syscall = 1;
> > break;
> > + case OPT_FALLBACK_KEXEC:
> > + do_fallback_kexec_syscall = 1;
> > + break;
> > }
> > }
> >
> > +fallback:
> > /* Reset getopt for the next pass. */
> > opterr = 1;
> > optind = 1;
> > @@ -1407,6 +1413,13 @@ int main(int argc, char *argv[])
> > result = my_load(type, fileind, argc, argv,
> > kexec_flags, entry);
> > }
> > + /* fallback to old kexec syscall */
> > + if (do_kexec_file_syscall && result != 0 && do_fallback_kexec_syscall) {
> > + fprintf(stderr, "Fallback to kexec syscall\n");
> > + do_kexec_file_syscall = 0;
> > + do_fallback_kexec_syscall = 0;
> > + goto fallback;
> > + }
> > /* Don't shutdown unless there is something to reboot to! */
> > if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded()) {
> > die("Nothing has been loaded!\n");
> > diff --git a/kexec/kexec.h b/kexec/kexec.h
> > index 9194f1c..65dbd56 100644
> > --- a/kexec/kexec.h
> > +++ b/kexec/kexec.h
> > @@ -225,7 +225,8 @@ extern int file_types;
> > #define OPT_LOAD_PRESERVE_CONTEXT 259
> > #define OPT_LOAD_JUMP_BACK_HELPER 260
> > #define OPT_ENTRY 261
> > -#define OPT_MAX262
> > +#define OPT_FALLBACK_KEXEC 262
> > +#define OPT_MAX263
> > #define KEXEC_OPTIONS \
> > { "help", 0, 0, OPT_HELP }, \
> > { "version",0, 0, OPT_VERSION }, \
> > @@ -244,6 +245,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 }, \
> > + { "fallback-kexec", 0, 0, OPT_FALLBACK_KEXEC }, \
> > { "debug", 0, 0, OPT_DEBUG }, \
> >
> > #define KEXEC_OPT_STR "h?vdfxyluet:ps"
> > --
> > 2.6.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed
Hi Baoquan,
Thanks for your response!
On Thu, Jul 14, 2016 at 05:51:24PM +0800, Baoquan He wrote:
> On 07/14/16 at 04:45pm, Lee, Chun-Yi wrote:
> > This patch adds a new "--fallback-kexec" option to give a chance to
> > fallback to old kexec syscall when file based kexec syscall operation
> > failed.
> >
> > This option works with --kexec-file-syscall to provide more flexible
> > way to adapt to different kernels that those kernels built with
> > different kexec syscall config or have different verification policy.
>
> Usually distribuition system uses script to build a framework to
> connect the kexec/kdump, makedumpfile utility chain. This can make user
> execute a very simple script command to implement kexec load or kexec
> jumping job. In this case script can do what you are trying to do.
>
Yes, the fallback function can be implemented by script. But a new kexec
option is useful to the distro that it may not provides help scripts to
user.
> Besides, have you actually met that kexec-file failed but old kexec
> syscall works? I mean how did you test it? I am wondering when it will
> happen.
>
> Thanks
> Baoquan
>
The currently mainline kernel allows to set CONFIG_KEXEC or CONFIG_KEXEC_FILE
individual. So if kexec found that the file based kexec syscall isn't
available then this is a case to fallback to old kexec.
Another case is when KEXEC_VERIFY_SIG is set, The fallback function is more
convenient to user to build his own kernel for using or testing. The kexec
tool can try old syscall when verification failed.
Thanks a lot!
Joey Lee
> >
> > Cc: Simon Horman
> > Cc: Petr Tesarik
> > Cc: Vivek Goyal
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > kexec/kexec.c | 13 +
> > kexec/kexec.h | 4 +++-
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/kexec/kexec.c b/kexec/kexec.c
> > index 500e5a9..e05b43f 100644
> > --- a/kexec/kexec.c
> > +++ b/kexec/kexec.c
> > @@ -969,6 +969,7 @@ void usage(void)
> >" preserve context)\n"
> >" to original kernel.\n"
> >" -s, --kexec-file-syscall Use file based syscall for kexec
> > operation\n"
> > + " --fallback-kexec Fallback to old kexec when file based
> > syscall failed\n"
> >" -d, --debug Enable debugging to help spot a
> > failure.\n"
> >"\n"
> >"Supported kernel file types and options: \n");
> > @@ -1204,6 +1205,7 @@ int main(int argc, char *argv[])
> > int do_unload = 0;
> > int do_reuse_initrd = 0;
> > int do_kexec_file_syscall = 0;
> > + int do_fallback_kexec_syscall = 0;
> > void *entry = 0;
> > char *type = 0;
> > char *endptr;
> > @@ -1226,9 +1228,13 @@ int main(int argc, char *argv[])
> > case OPT_KEXEC_FILE_SYSCALL:
> > do_kexec_file_syscall = 1;
> > break;
> > + case OPT_FALLBACK_KEXEC:
> > + do_fallback_kexec_syscall = 1;
> > + break;
> > }
> > }
> >
> > +fallback:
> > /* Reset getopt for the next pass. */
> > opterr = 1;
> > optind = 1;
> > @@ -1407,6 +1413,13 @@ int main(int argc, char *argv[])
> > result = my_load(type, fileind, argc, argv,
> > kexec_flags, entry);
> > }
> > + /* fallback to old kexec syscall */
> > + if (do_kexec_file_syscall && result != 0 && do_fallback_kexec_syscall) {
> > + fprintf(stderr, "Fallback to kexec syscall\n");
> > + do_kexec_file_syscall = 0;
> > + do_fallback_kexec_syscall = 0;
> > + goto fallback;
> > + }
> > /* Don't shutdown unless there is something to reboot to! */
> > if ((result == 0) && (do_shutdown || do_exec) && !kexec_loaded()) {
> > die("Nothing has been loaded!\n");
> > diff --git a/kexec/kexec.h b/kexec/kexec.h
> > index 9194f1c..65dbd56 100644
> > --- a/kexec/kexec.h
> > +++ b/kexec/kexec.h
> > @@ -225,7 +225,8 @@ extern int file_types;
> > #define OPT_LOAD_PRESERVE_CONTEXT 259
> > #define OPT_LOAD_JUMP_BACK_HELPER 260
> > #define OPT_ENTRY 261
> > -#define OPT_MAX262
> > +#define OPT_FALLBACK_KEXEC 262
> > +#define OPT_MAX263
> > #define KEXEC_OPTIONS \
> > { "help", 0, 0, OPT_HELP }, \
> > { "version",0, 0, OPT_VERSION }, \
> > @@ -244,6 +245,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 }, \
> > + { "fallback-kexec", 0, 0, OPT_FALLBACK_KEXEC }, \
> > { "debug", 0, 0, OPT_DEBUG }, \
> >
> > #define KEXEC_OPT_STR "h?vdfxyluet:ps"
> > --
> > 2.6.6
> >
> >
> > ___
> > kexec mailing list
> > kexec@lists.infradead.org
Re: [PATCH] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()
Hi Minfei,
On Tue, Sep 29, 2015 at 11:50:44AM +0800, Minfei Huang wrote:
> On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> > On big machines have CPU number that's very nearly to consume whole ELF
> > headers buffer that's page aligned, 4096, 8192... Then the page fault error
> > randomly happened.
> >
> > This patch modified the code in fill_up_crash_elf_data() by using
> > walk_system_ram_res() instead of walk_system_ram_range() to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range()
> > filters out small memory regions that reside the same page, but
> > walk_system_ram_res() does not.
> >
> > The oringial page fault issue sometimes happened on big machines when
> > preparing ELF headers:
> >
> > [ 305.291522] BUG: unable to handle kernel paging request at
> > c90613fc9000
> > [ 305.299621] IP: []
> > prepare_elf64_ram_headers_callback+0x165/0x260
> > [ 305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [ 305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [ 305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti:
> > 8e1c03ec2000
> > [ 305.429292] RIP: 0010:[] []
> > prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> >
> > After tracing prepare_elf64_headers() and
> > prepare_elf64_ram_headers_callback(),
> > the code uses walk_system_ram_res() to fill-in crash memory regions
> > information
> > to program header, so it counts those small memory regions that reside in a
> > page area. But, when kernel was using walk_system_ram_range() in
> > fill_up_crash_elf_data() to count the number of crash memory regions, it
> > filters out small regions.
> >
> > I printed those small memory regions, for example:
> >
> > kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258,
> > sz=0xdc0
> >
> > Base on the logic of walk_system_ram_range(), this memory region will be
> > filter out:
> >
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) [FAIL]
> >
> > So, the max_nr_ranges that counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers,
> >
> > This issue was hided on small machine that doesn't have too many CPU because
> > the free space of ELF headers buffer can cover the number of small memory
> > regions. But, when the machine has more CPUs or the number of memory regions
> > very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> > issue will happen randomly.
> >
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > arch/x86/kernel/crash.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index e068d66..ad273b3d 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -185,8 +185,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> > }
> >
> > #ifdef CONFIG_KEXEC_FILE
> > -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> > - unsigned long nr_pfn, void *arg)
> > +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
> > {
> > int *nr_ranges = arg;
>
> Ccing kexec maillist.
>
> Good cacthing.
>
> It is appreciate if you can change the above type to unsigned int
> accordingly.
>
> Thanks
> Minfei
>
Looks unsigned int* is better, I will change in next version.
Thanks for your review.
Joey Lee
> >
> > @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct
> > crash_elf_data *ced,
> >
> > ced->image = image;
> >
> > - walk_system_ram_range(0, -1, &nr_ranges,
> > + walk_system_ram_res(0, -1, &nr_ranges,
> > get_nr_ram_ranges_callback);
> >
> > ced->max_nr_ranges = nr_ranges;
> > --
> > 2.1.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
