linux-kernel - Re: vvar, gup && coredump

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]

Message-ID: <20150313150417.GE21603@redhat.com>
Date:	Fri, 13 Mar 2015 16:04:17 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Sergio Durigan Junior <sergiodj@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	GDB Patches <gdb-patches@...rceware.org>,
	Pedro Alves <palves@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: vvar, gup && coredump

On 03/13, Sergio Durigan Junior wrote:
>
> On Thursday, March 12 2015, Oleg Nesterov wrote:
>
> > And it seems that we all agree that the kernel should not dump this vma
> > too. Could you confirm that this is fine from gdb pov just in case?
>
> Yes, this is what we expect from the GDB side.  This mapping is marked
> as "dd", so it does not make sense to dump it.

OK.

> While I have you guys, would it be possible for the Linux kernel to
> include a new flag on VmFlags to uniquely identify an anonymous mapping?

Note that "anonymous" is not the right term here... I mean it is a bit
confusing. Lets discuss this again on debug-list, then we will see if
gdb needs more info from kernel.

> Currently, there is no easy way to do that from userspace.  My patch
> implements the following heuristic on GDB:
>
>   if (pathname == "/dev/zero (deleted)"
>       || pathname == "/SYSV%08x (deleted)"
>       || pathname == "<file> (deleted)"

And for example, this is not anonymous mapping. But,

>     mapping is anonymous;

I agree, gdb should treat it as anonymous.

> However, this can be fragile.  The Linux kernel checks for i_nlink == 0,

Yes, as we already disccussed, I think the kernel should be changed.

It should do something like shmem_mapping() || d_unlinked(), I think.
But this needs another discussion on lkml, and in another thread.

Oleg.

--
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/