linux-kernel - Re: [PATCH -mm v2] coredump: extend core dump note section to contain file names of mapped files

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 19 Sep 2012 18:16:53 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Roland McGrath <roland@...k.frob.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Amerigo Wang <amwang@...hat.com>,
	"Jonathan M. Foote" <jmfoote@...t.org>,
	Pedro Alves <palves@...hat.com>
Subject: Re: [PATCH -mm v2] coredump: extend core dump note section to contain
 file names of mapped files

On Tue, Sep 18, 2012 at 6:58 PM, Roland McGrath <roland@...k.frob.com> wrote:
> The code needs to be macroized a bit so that compat_binfmt_elf.c will
> produce a version that encodes 32-bit values correctly so as to be
> compatible with the output of a native 32-bit kernel.

Just did it...

> It's doubtful that rolling your own single loop actually performs better
> than just calling strlen and memcpy.

I didn't do it for speed, rather for simplicity.

> Since you're just counting to estimate the size of a temporary buffer,
> you could skip the initial loop and just estimate based on mm->map_count.
> Then collect the count in the main loop and write the first word of the
> buffer last.

The format is:

    long count     -- how many files are mapped
    long page_size -- units for file_ofs
    array of [COUNT] elements of
       long start
       long end
       long file_ofs
    followed by COUNT filenames in ASCII: "FILE1" NUL "FILE2" NUL...

In order to fill in file names, we need to know exact number of array elements,
since file names immediately follow that array. IOW:

+       for (vma = current->mm->mmap; vma != NULL; vma = vma->vm_next) {
+               if (it is a file-backed vma)
+                       count++;
+       }
+
+       size = count * 64;
+       word_count = 2 + 3 * count;               <=====
...
+       name = (void*)&start_end_ofs[word_count]; <=====

The marked statements are crucial. We can't use estimated count,
we need exact one here in order for 'name' pointer to be correct.

Otherwise (if we would use count = mm->map_count),
we'd need to memmove block of file names at the end.
And we might end up allocating significant amounts of memory
we don't need if there are tons of anon mappings.
IMO this is worse than the counting loop.

Anyway, I will shortly send a patch which implements your logic.
-- 
vda
--
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/