linux-kernel - Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

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 PHC
Open Source and information security mailing list archives

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

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

Date:   Fri, 24 Feb 2017 15:39:38 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Pratyush Anand <panand@...hat.com>,
        open list <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>,
        Dave Anderson <anderson@...hat.com>,
        Kexec Mailing List <kexec@...ts.infradead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        ebiederm@...ssion.com
Subject: Re: [PATCH] /proc/kcore: Update physical address for kcore ram and
 text

CC Eric too.

On 02/13/17 at 02:25pm, Kees Cook wrote:
> On Mon, Jan 30, 2017 at 11:00 AM, Pratyush Anand <panand@...hat.com> wrote:
> > CCing Andrew and Kees for their review comments.
> >
> >
> > On Wednesday 25 January 2017 10:14 AM, Pratyush Anand wrote:
> >> 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.
> >>
> >> Signed-off-by: Pratyush Anand <panand@...hat.com>
> >> ---
> >> 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;
> >> }
> >>
> 
> Well, CONFIG_PROC_KCORE is a generalized root KASLR exposure (though
> there are lots of such exposures). Why is the actual physical address
> needed? Can this just report the virtual address instead? Then the
> tool can build a map, but it looks like an identity map, rather than
> creating a new physical/virtual memory ASLR offset exposure?

HPE asked to add a dumped vmcore size estimate feature to makedumpfile,
just like HP UNIX does. So I added a --mem-usage option to makedumpfile
and use /proc/kcore to analyze the memory of 1st kernel. Since /proc/kcore
is a elf file which contains the mm layout of 1st kernel, it can help us
estimate how much disk space need be reserved. Later s390x people also
add support for this feature.

With kaslr enabled, page_offset becomes uncertain, and in kernel Eric
doesn't suggest exporting them into vmcoreinfo. So Pratyush tried to add
physical address of direct mapping regions. For kaslr, kcore has
exported those randomized starting address, I am not sure if it's risky
to export physical address.

It's close to our rhel dev cycle deadline, we hope this can be merged
soon. I believe we can discuss it and improve it any time if risk is
felt.

Thanks
Baoquan