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: <20120305173314.GA17895@redhat.com>
Date:	Mon, 5 Mar 2012 18:33:14 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Kees Cook <keescook@...omium.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] turn mm->exe_file into mm->exe_path

On 03/05, Cyrill Gorcunov wrote:
>
> On Mon, Mar 05, 2012 at 04:28:26PM +0100, Oleg Nesterov wrote:
> > I think the patch is simple and self-explanatory, it simply
> > does s/mm->exe_file/mm->exe_path/.
> >
> > Why do we need mm->exe_file? IIUC, there are 2 reasons:
> >
> > 	1. we do not want O(n) proc/pid/exe looking for the 1st
> > 	   VM_EXECUTABLE vma.
> >
> > 	2. we do not want to rely on vma->vm_file->f_path,
> > 	   bprm->file->f_op->mmap can change ->vm_file.
> >
> > Unless there was another subtle reason, "struct path *exe_path"
> > can equally work but it looks more clear.
> >
> > And can't we also remove added_exe_file_vma/removed_exe_file_vma?
> > Why do we need mm->num_exe_file_vmas? Afaics it is only needed to
> > "free" mm->exe_file if the application unmaps all these vmas. Say,
> > to allow to unmount fs.
> >
> > Can't we simply add PR_CLEAR_MM_EXE_PATH instead? Of course it is
> > not enough if ->vm_file still has a reference. But c/r people want
> > PR_SET_MM_EXE_FILE anyway, see http://marc.info/?t=133052865500016
> > So perhaps we can add PR_SET_MM_EXE_PATH which accepts NULL as well
> > and kill this counter?
> >
>
> So, if I understand you correctly, if there is exe_path, I would
> simply put() it and get() and assign new one. Looks cool for me.

Yes,

> Not sure where we may use PR_SET_MM_EXE_PATH with NULL to kill
> num_exe_file_vmas from user space though

Please see above:

	Why do we need mm->num_exe_file_vmas? Afaics it is only needed to
	"free" mm->exe_file if the application unmaps all these vmas. Say,
	to allow to unmount fs.

If we remove this counter, the application can't do the final put.
But if we add PR_SET_MM_EXE_PATH which accepts NULL we solve this
problem and this works for c/r too.

Of course, this is orthogonal to the patch I sent.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ