linux-kernel - Re: [patch v3 3/8] kdump: Add size to elfcorehdr kernel parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Aug 2011 19:56:46 +0200
From:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	ebiederm@...ssion.com, mahesh@...ux.vnet.ibm.com, hbabu@...ibm.com,
	oomichi@....nes.nec.co.jp, horms@...ge.net.au,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-s390@...r.kernel.org
Subject: Re: [patch v3 3/8] kdump: Add size to elfcorehdr kernel parameter

Hello Vivek,

On Thu, 2011-08-18 at 13:28 -0400, Vivek Goyal wrote:
> > The parameter is parsed in common code (kernel/crash_dump.c) in
> > early_param("elfcorehdr", setup_elfcorehdr), as it is already currently
> > the case.
> > 
> > We use address and size of the ELF core header to reserve the header
> > memory in setup.c (see patch #8):
> > 
> > +#ifdef CONFIG_CRASH_DUMP
> > +       if (is_kdump_kernel())
> > +               reserve_bootmem(elfcorehdr_addr - OLDMEM_BASE,
> > +                               PAGE_ALIGN(elfcorehdr_size), BOOTMEM_DEFAULT);
> > +#endif
> > 
> > Does that answer your question?
> 
> Yes it does. Thanks.
> 
> It brings up few more questions about rest of the memory mangement.
> 
> So kdump kernel is loaded in reserved area but does not run from there.
> It reloads itself into lower memory areas and swaps the contents of
> lower memory with reserved memory? If yes, how does it, kernel or
> purgatory?

With the v3 patch series purgatory does that (see
purgatory-s390.c/post_verification_setup_arch()):

> How does kernel come to know about how much memory is to be swapped

2nd kernel knows crash_base and crash_base because kexec tools told him
that. We do it like registering the ramdisk. See kexec-image.c:

+               if (info->kexec_flags & KEXEC_ON_CRASH) {
+                       tmp = krnl_buffer + OLDMEM_BASE_OFFS;
+                       *tmp = crash_base;
+
+                       tmp = krnl_buffer + OLDMEM_SIZE_OFFS;
+                       *tmp = crash_end - crash_base + 1;
+               }

> and how do you bound the memory usage of second kernel so that it
> does not try to use other memory which has not been swapped into
> reserved area.

See kernel patches setup.c:

+/*
+ * Make sure that oldmem, where the dump is stored, is protected
+ */
+static void reserve_oldmem(void)
+{
+#ifdef CONFIG_CRASH_DUMP
+       if (!is_kdump_kernel())
+               return;
+
+       reserve_kdump_bootmem(OLDMEM_BASE, OLDMEM_SIZE, CHUNK_OLDMEM);
+       reserve_kdump_bootmem(OLDMEM_SIZE, memory_end - OLDMEM_SIZE,
+                             CHUNK_OLDMEM);
+       if (OLDMEM_BASE + OLDMEM_SIZE == real_memory_size)
+               saved_max_pfn = PFN_DOWN(OLDMEM_BASE) - 1;
+       else
+               saved_max_pfn = PFN_DOWN(real_memory_size) - 1;
+#endif
+}

Michael










--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/