linux-kernel - Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe

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: <20120310074854.GA3065@moon>
Date:	Sat, 10 Mar 2012 11:48:54 +0400
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Kees Cook <keescook@...omium.org>, Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3

On Fri, Mar 09, 2012 at 03:59:01PM -0800, Matt Helsley wrote:
> > Well, in final version I switched back to
> > 
> > +	if (mm->num_exe_file_vmas)
> > +		return -EBUSY;
> > 
> > simply because it's more flexible than mm->exe_file.
> > 
> > With mm->exe_file this prctl option become a one-shot
> > only, and while at moment our user-space tool can perfectly
> > live with that I thought that there is no strict need to
> > limit the option this way from the very beginning.
> 
> As far as backward compatibility, isn't it better to lift that restriction
> later rather than add it? I think the latter would very likely "break"
> things whereas the former would not.

Indeed. But I think any change will mean compatibility broken, programs
may rely on one-shot or multi-shot behaviour. So I personally vote
for more flexible approach here.

> 
> I also prefer that restriction because it establishes a bound on how
> frequently the symlink can change. Keeping it a one-shot deal makes the
> values that show up in tools like top more reliable for admins.

How? Once exe_file changed -- we already cheating the kernel, it's not
bad, not good, just work this way ;) I mean imagine an admin which
runs top and sees some program in 'top' ouput (btw, I'm not sure but
does top really parse /proc/pid/exe?) so say he sees some programs
names -- how would he know if a program did change own /proc/pid/exe
at all? Note it's not that important how many times the symlink was
changed there is simply no way to find out if it was changed at all,
and actually from my POV it's a win for transparent c/r, that was
all the idea.

> > 
> > As far as I understand overall num_exe_file_vmas concept -- we track
> > a number of VM_EXECUTABLE with it, so setting new exe_file should not
> > change num_exe_file_vmas I think.
> 
> True, it's literally correct. However the whole reason for having it
> is to turn the mm->exe_file reference into a sort of weak reference
> which happens to coincide with counting the number of VM_EXECUTABLE vmas
> until you do c/r (really just the restart side of c/r).
> 

Look. We actually have a period of time where exe_file is set but
num_exe_file_vmas = 0 when we start program execution before elf
map get parsed, so I dare to say such state is legitime (yes, userspace
doesn't see this state and yes, we start mapping elf sections pretty
immediately after exe_file assigned). So I don't see much problem in
extending this "state" (exe_file!=0,num_exe_file_vmas = 0).

Thanks for comments, Matt!

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