linux-kernel - Re: [PATCH -mm] sys_unshare: simplify the not-really-implemented CLONE

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]

Date:	Wed, 24 Mar 2010 00:05:26 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Badari Pulavarty <pbadari@...ibm.com>,
	Christoph Hellwig <hch@....de>, Janak Desai <janak@...ibm.com>,
	Roland McGrath <roland@...hat.com>,
	Stanislaw Gruszka <sgruszka@...hat.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] sys_unshare: simplify the not-really-implemented
	CLONE_THREAD/SIGHAND/VM code

On 03/23, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@...hat.com> writes:
>
> > (on top of check_unshare_flags-kill-the-bogus-clone_sighand-sig-count-check.patch)
> >
> > Cleanup.
> >
> > sys_unshare(CLONE_THREAD/SIGHAND/VM) is not really implemented, and I doubt
> > very much it will ever work. At least, nobody even tried since the original
> > "unshare system call -v5: system call handler function" commit
> > 99d1419d96d7df9cfa56bc977810be831bd5ef64 was applied more than 4 years ago.
> >
> > And the code is not consistent. unshare_thread() always fails unconditionally,
> > while unshare_sighand() and unshare_vm() pretend to work if there is nothing
> > to unshare.
>
> This is setting off alarm bells in my head.
>
> I haven't traced this all through but I like your logic a lot less, and
> I think it is buggy.  Why don't we need to look at sigh->count ?

CLONE_SIGHAND needs CLONE_VM in copy_process(). It is not possible that
sighand->count > 1 while mm->mm_users <= 1.

> The current logic is very fine grained but it does a lot of simple logical
> checks and it ties those checks together if a very maintainable way.

I'd say the current simple logic is simple but wrong ;)

Before the recent changes check_unshare_flags() did

	if (*flags_ptr & CLONE_THREAD)
		*flags_ptr |= CLONE_VM;

	...
	
	if ((*flags_ptr & CLONE_SIGHAND) &&
	    (atomic_read(&current->signal->count) > 1))
		*flags_ptr |= CLONE_THREAD;

Now, if we add CLONE_THREAD, why we do not add CLONE_VM here? This is
not right.

And why unshare_thread() always fails even in single-threaded case?

But,

> You require that we know upfront all of the dependencies, which is things
> change subtlety can be a maintenance challenge.

Fortunately this all is not implemented anyway.

My point was: lets simplify this code, mainly to reduce the output from, say,
"grep CLONE_SIGHAND". In my opinion, it is a bit strange that the code which
doesn't really work adds the unnecessary dependencies to CLONE_THREAD/etc
subtleness.

> > Note: with or without this patch "atomic_read(mm->mm_users) > 1" can give
> > a false positive due to get_task_mm().
>
> I think the number of times get_task_mm is called on not current this isn't
> an interesting race.

Sure. I just meant that this check is wrong, but it was copied from the
current code. We could use current_is_single_threaded() though.


That said, I do not really care about this cleanup. I did it just because
I sent another patch which touches check_unshare_flags(), and I was really
surprised that ~70 lines in kernel/fork.c do nothing but confuse the reader.

Please nack this patch and lets forget it ;)

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/