[RFC] apparently broken RLIMIT_CORE

[RFC] apparently broken RLIMIT_CORE

[Al Viro]

	elf_core_dump() writes struct elfhdr, then a bunch of
elf_phdr.  It sums the sizes of data being written in 'size',
checking it against cprm->limit as it goes.

	So far, so good, but then it proceeds to write_note_info(),
which neither checks overflows nor contributes to size.  _Then_
it seeks to page boundary and proceeds to loop over the pages,
writing them to dump.  At that point it again starts to count sizes,
bump size and check it against cprm->limit (only for present pages,
though - absent ones are silently skipped, with lseek() done on
output and size not increased).

	In other words, the size of notes section is ignored for
RLIMIT_CORE purposes.  Is that intentional?  Looks like a bug to
me...  FWIW, POSIX says that limit is on the file size and demands
that write would stop at that length, with 0 meaning "suppress
coredump creation completely".  I'm not sure how the holes should
be treated (note, BTW, that when output goes into a pipe we do
feed zeroes into it for absent pages for obvious reasons, but we
do not count them towards the limit), but ignoring the notes doesn't
look intentional...

	Comments?

Re: [RFC] apparently broken RLIMIT_CORE

[Linus Torvalds]

On Sat, Oct 5, 2013 at 5:43 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         In other words, the size of notes section is ignored for
> RLIMIT_CORE purposes.  Is that intentional?

I doubt it is intentional, but I also cannot really feel that we care
deeply. Afaik we don't really honor the size limit exactly anyway, ie
we tend to check only at page boundaries etc. So do we really care?

               Linus

Re: [RFC] apparently broken RLIMIT_CORE

[Ulrich Drepper]

On Sun, Oct 6, 2013 at 4:42 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I doubt it is intentional, but I also cannot really feel that we care
> deeply. Afaik we don't really honor the size limit exactly anyway, ie
> we tend to check only at page boundaries etc. So do we really care?

I could imagine in the case Al brought up (a pipe as core file filter)
we might want to have some assurance the limits are not breached.  If
it doesn't cost that much I'd say implement it precisely.

Re: [RFC] apparently broken RLIMIT_CORE

[Al Viro]

On Sun, Oct 06, 2013 at 01:42:05PM -0700, Linus Torvalds wrote:
> On Sat, Oct 5, 2013 at 5:43 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         In other words, the size of notes section is ignored for
> > RLIMIT_CORE purposes.  Is that intentional?
> 
> I doubt it is intentional, but I also cannot really feel that we care
> deeply. Afaik we don't really honor the size limit exactly anyway, ie
> we tend to check only at page boundaries etc. So do we really care?

It's actually easier to put the counter of already written data into
coredump_params and have a new primitive both check that we won't
exceed the limit and update that counter, rather than doing it manually
(and somewhat inconsistently) in load_elf_binary() and the stuff it
calls.  As the matter of fact, after that change we get code looking
so:
        if (!elf_core_write_extra_phdrs(cprm, offset))
                goto end_coredump;

        size = cprm->written;
        /* write out the notes section */
        if (!write_note_info(&info, cprm))
                goto end_coredump;

        if (elf_coredump_extra_notes_write(cprm))
                goto end_coredump;

        /* Align to page */   
        if (!dump_seek(cprm->file, dataoff - cprm->written))
                goto end_coredump;

        cprm->written = size;
        for (vma = first_vma(current, gate_vma); vma != NULL;
                        vma = next_vma(vma, gate_vma)) {
and that's the only remaining reason to have size as local variable at all.
IOW, making the it consistent would mean getting rid of this "save and restore
cprm->written" thing around write_note_info()/elf_coredump_extra_notes_write()
in there...

Objections?

PS: I've ended up modifying aout32 coredump code (after fixing the bitrot in
there), now the problem is how to test it.  I'm grabbing something I hadn't
seen in a _long_ time - i386 Slackware 2.3; that should still contain live
a.out toolchain and as long as it's run under KVM and isolated from network...

Re: [RFC] apparently broken RLIMIT_CORE

[Linus Torvalds]

On Sun, Oct 6, 2013 at 2:33 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Objections?

No objections, my comment was more of a "probably nobody cares" rather
than much of an objection to you deciding you care enough to fix it..

            Linus