linux-kernel - Re: [PATCH 1/9] exec_path 1/9: introduce ->exec

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: <20090605174637.GA13567@x200.localdomain>
Date:	Fri, 5 Jun 2009 21:46:37 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Helsley <matthltc@...ibm.com>, xemul@...allels.com,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, dave@...ux.vnet.ibm.com,
	mingo@...e.hu, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/9] exec_path 1/9: introduce ->exec_path and switch
	/proc/*/exe

On Fri, Jun 05, 2009 at 09:48:02AM -0700, Linus Torvalds wrote:
> On Fri, 5 Jun 2009, Alexey Dobriyan wrote:
> > 
> > It's borrowed by kernel thread of course, not userspace task.
> 
> .. and even if it is, what's the problem? 

The problem is task_struct <=> mm_struct relationship is muzzled
for various reasons, and to not depend on subtleties of who-owns-mm-struct
of the day, ->exec_path is placed onto task_struct.

Done this, ->exec_path simply stop depend on other current and future
hacks, and only defined by what binfmt loader did.

> That kernel thread has borroed whe VM for a while. It effectively _is_ a 
> thread of the process now.

See? Thread is what you get via CLONE_THREAD.

> So it's technically not even wrong to 
> explicitly allow things like /proc/*/exe to see it as such.

This knowledge is some implementation detail, how AIO is implemented and
how kernel threads access userpace VM. But you're going to expose it
by not checking for kernel-threadness or something.

> But you can hide it by just checking some flag in the thread structure if 
> you really want to.
> 
> But when creating a regular thread, you should _not_ need to take a 
> spinlock and duplicate the executable path!

Since task_struct is literally copied during clone, _that_ line,
can be easily changed to just

	path_get(&p->exec_path);

But for consistency and to not give bad example it was written
with honest locking.
--
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/