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:	Thu, 19 Nov 2009 03:28:16 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Luck, Tony" <tony.luck@...el.com>, Jiri Slaby <jslaby@...ell.com>,
	"jirislaby@...il.com" <jirislaby@...il.com>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	"sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"marcin.slusarz@...il.com" <marcin.slusarz@...il.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, James Morris <jmorris@...ei.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>
Subject: Re: [PATCH 03/16] IA64: use ACCESS_ONCE for rlimits


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> So the rule is: if you access unlocked values, you use ACCESS_ONCE(). 
> You don't say "but it can't matter". Because you simply don't know.

Most of the time we are being lax about it, especially when it's some 
global value we are accessing, which can only be changed as a sysadmin 
via a sysctl or so.

[ For example we access pid_max in kernel/pid.c, outside of any lock and 
  without ACCESS_ONCE() - but that particular case is not a big deal 
  because changes to pid_max via a sysctl are so rare and are 
  privileged, and because the effects of any race there are benign. ]

But this patch series is about setrlimit, which makes the per task 
rlimit value pretty SMP-volatile (a parallel, unprivileged setrlimit can 
race with usage of the value elsewhere) - and the rlimits have security 
relevance as well so some extra care in accessing them outside of locks 
is prudent IMO.

	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/

Powered by blists - more mailing lists