linux-kernel - RE: [PATCH 00/13] [RFC] Rust support

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:   Sat, 17 Apr 2021 12:41:23 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Peter Zijlstra' <peterz@...radead.org>,
        Wedson Almeida Filho <wedsonaf@...gle.com>
CC:     "ojeda@...nel.org" <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/13] [RFC] Rust support

From: Peter Zijlstra
> Sent: 16 April 2021 15:19
> 
> On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> > On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
> 
> > >  int perf_event_task_enable(void)
> > >  {
> > > +	DEFINE_MUTEX_GUARD(event_mutex, &current->perf_event_mutex);
> >
> > There is nothing in C forcing developers to actually use DEFINE_MUTEX_GUARD. So
> > someone may simply forget (or not know that they need) to lock
> > current->perf_event_mutex and directly access some field protected by it. This
> > is unlikely to happen when one first writes the code, but over time as different
> > people modify the code and invariants change, it is possible for this to happen.
> >
> > In Rust, this isn't possible: the data protected by a lock is only accessible
> > when the lock is locked. So developers cannot accidentally make mistakes of this
> > kind. And since the enforcement happens at compile time, there is no runtime
> > cost.
> >
> > This, we believe, is fundamental to the discussion: we agree that many of these
> > idioms can be implemented in C (albeit in this case with a compiler extension),
> > but their use is optional, people can (and do) still make mistakes that lead to
> > vulnerabilities; Rust disallows classes of  mistakes by construction.
> 
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
> 
> That's a semi common scheme in the kernel, but not something that's
> expressible by, for example, the Java sync keyword.
> 
> It also very much doesn't work for RCU, where modification must be done
> under a lock, but access is done essentially lockless.
...

Or the cases where the locks are released in the 'wrong' order.
Typically for:
	lock(table)
	item = lookup(table, key)
	lock(item)
	unlock(table)
	...
	unlock(item)

(In the kernel the table lock might be RCU.)

Or, with similar data:
	write_lock(table);
	foreach(item, table)
		lock(item)
		unlock(item)
	/* No items can be locked until we release the write_lock.
	...
	unlock(table)

You can also easily end up with a 'fubar' we have at work where
someone wrote a C++ condvar class that inherits from mutex.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)