[patch] Kernel patch

linux-kernel-proc-kcore-update-physical-address-for-kcore-ram-and.patch (text/plain), 3.23 KB, created by Xiami on 2017-12-28 09:06:12 UTC

From 464920104bf7adac12722035bfefb3d772eb04d8 Mon Sep 17 00:00:00 2001
From: Pratyush Anand <[e-mail]>
Date: Mon, 27 Feb 2017 14:27:31 -0800
Subject: [PATCH] /proc/kcore: update physical address for kcore ram and text

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.

User space tools like makedumpfile needs to know physical address for
PT_LOAD segments of direct mapped regions.  Therefore this patch updates
paddr for such regions.  It also sets an invalid paddr (-1) for other
regions, so that user space tool can know whether a physical address
provided in PT_LOAD is correct or not.

I do not know why it was 0, which is a valid physical address.  But
certainly, it might break some user space tools, and those need to be
fixed.  For example, see following code from kexec-tools

kexec/kexec-elf.c:build_mem_phdrs()

                    if ((phdr->p_paddr + phdr->p_memsz) < phdr->p_paddr) {
                            /* The memory address wraps */
                            if (probe_debug) {
                                    fprintf(stderr, "ELF address wrap around\n");
                            }
                            return -1;
                    }

We do not need to perform above check for an invalid physical address.

I think, kexec-tools and makedumpfile will need fixup.  I already have
those fixup which will be sent upstream once this patch makes through.
Pro with this approach is that, it will help to calculate variable like
page_offset, phys_base from PT_LOAD even when they are randomized and
therefore will reduce many variable and version specific values in user
space tools.

Having an ASLR offset information can help to translate an identity
mapped virtual address to a physical address.  But that would be an
additional field in PT_LOAD header structure and an arch dependent
value.

Moreover, sending a valid physical address like 0 does not seem right.
So, IMHO it is better to fix that and send valid physical address when
available (identity mapped).

Link: http://lkml.kernel.org/r/[e-mail]
Signed-off-by: Pratyush Anand <[e-mail]>
Cc: Baoquan He <[e-mail]>
Cc: Dave Young <[e-mail]>
Cc: Dave Anderson <[e-mail]>
Cc: Atsushi Kumagai <[e-mail]>
Cc: Simon Horman <[e-mail]>
Cc: Kees Cook <[e-mail]>
Signed-off-by: Andrew Morton <[e-mail]>
Signed-off-by: Linus Torvalds <[e-mail]>
---
 fs/proc/kcore.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 0b80ad87b4d6..ea9f3d1ae830 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -373,7 +373,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, int dataoff)
 		phdr->p_flags	= PF_R|PF_W|PF_X;
 		phdr->p_offset	= kc_vaddr_to_offset(m->addr) + dataoff;
 		phdr->p_vaddr	= (size_t)m->addr;
-		phdr->p_paddr	= 0;
+		if (m->type == KCORE_RAM || m->type == KCORE_TEXT)
+			phdr->p_paddr	= __pa(m->addr);
+		else
+			phdr->p_paddr	= (elf_addr_t)-1;
 		phdr->p_filesz	= phdr->p_memsz	= m->size;
 		phdr->p_align	= PAGE_SIZE;
 	}
-- 
2.13.6