linux-kernel - Re: [PATCH 0/4] v6 Improve task->comm locking situation

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: <20110518062554.GB2945@elte.hu>
Date:	Wed, 18 May 2011 08:25:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	John Stultz <john.stultz@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Joe Perches <joe@...ches.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Andy Whitcroft <apw@...onical.com>,
	Jiri Slaby <jirislaby@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...gle.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/4] v6 Improve task->comm locking situation


* John Stultz <john.stultz@...aro.org> wrote:

> v6 tries to address the latest round of issues. Again, hopefully this is 
> getting close to something that can be queued for 2.6.40.

We are far away from thinking about upstreaming any of this ...

> Since my commit 4614a696bd1c3a9af3a08f0e5874830a85b889d4, the current->comm 
> value could be changed by other threads.
> 
> This changed the comm locking rules, which previously allowed for unlocked 
> current->comm access, since only the thread itself could change its comm.
> 
> While this was brought up at the time, it was not considered problematic, as 
> the comm writing was done in such a way that only null or incomplete comms 
> could be read. However, recently folks have made it clear they want to see 
> this issue resolved.

The commit is from 2.5 years ago:

        4614a696bd1c3a9af3a08f0e5874830a85b889d4
        Author: john stultz <johnstul@...ibm.com>
        Date:   Mon Dec 14 18:00:05 2009 -0800

            procfs: allow threads to rename siblings via /proc/pid/tasks/tid/comm

So we are *way* beyond the time frame where this could be declared urgent.

So is there any actual motivation beyond:

  " Hey, this looks a bit racy and 'top' very rarely, on rare workloads that 
    play with ->comm[], might display a weird reading task name for a second, 
    amongst the many other temporarily nonsensical statistical things it 
    already prints every now and then. "

?

> So fair enough, as I opened this can of worms, I should work
> to resolve it and this patchset is my initial attempt.

This patch set does not address the many places that deal with ->comm so it 
does not even approximate the true scope of the change!

I.e. you are doing *another* change without fully seeing/showing the 
consequences ...

Thanks,

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