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-next>] [day] [month] [year] [list]
Date:	Thu, 10 Dec 2009 00:52:46 -0000
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Oleg Nesterov <oleg@...sign.ru>,
	Al Viro <viro@...iv.linux.org.uk>,
	James Morris <jmorris@...ei.org>,
	David Howells <dhowells@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [patch 0/9] Fix various __task_cred related invalid RCU assumptions

While auditing the read_lock(&tasklist_lock) sites for a possible
conversion to rcu-read_lock() I stumbled over an unprotected user of
__task_cred in kernel/sys.c

That caused me to audit all the __task_cred usage sites except in
kernel/exit.c.

Most of the usage sites are correct, but some of them trip over
invalid assumptions about the protection which is given by RCU.

- spinlocked/preempt_disabled regions are equivalent to rcu_read_lock():

   That's wrong. RCU does not guarantee that. 

   It has been that way due to implementation details and it still is
   valid for CONFIG_TREE_PREEMPT_RCU=n, but there is no guarantee that
   this will be the case forever.

- interrupt disabled regions are equivalent to rcu_read_lock():

  Wrong again. RCU does not guarantee that.

  It's true for current mainline, but again this is an implementation
  detail and there is no guarantee by the RCU semantics.

  Indeed we want to get rid of that to avoid scalability issues on
  large systems and preempt-rt got already rid of it to a certain
  extent.

I'm sure we are lucky that CONFIG_TREE_PREEMPT_RCU=y is not yet wide
spread and the code pathes are esoteric enough not to trigger that
subtle races (some of them might just error out silently).

Nevertheless we need to fix all invalid assumptions about RCU
protection.

The following patch series fixes all yet known affected __task_cred()
sites, but there is more auditing of all other rcu users necessary.

Thanks,

	tglx

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