linux-kernel - Re: [PATCH 01/11] sysctl: Separate the binary sysctl logic into it's own file.

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:	Fri, 6 Nov 2009 14:11:19 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] sysctl: Separate the binary sysctl logic into it's own file.

On Friday 06 November 2009, Eric W. Biederman wrote:
> The primary proc path already doesn't need the lock_kernel().  My next
> patch winds up killing the entire binary path and rebuilding on top of
> /proc/sys.  Which removes that lock_kernel().
> 
> Which I think elegantly solves all of the sysctl BKL lock issues.

Yes, that sounds like an excellent plan, but I'm not completely sure
if the lack of the BKL in the procfs case is intentional. As a
particular case that I stumbled over, 'core_pattern' is read
with the BKL held to protect against sysctl changing it, but
it is changed with proc_dostring without the BKL.

Most uses of intvec or string seem to be racy and probably need
a proper serialization method anyway.

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