linux-kernel - Re: Memory allocator semantics

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:	Tue, 11 Feb 2014 07:01:13 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Christoph Lameter <cl@...ux.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Matt Mackall <mpm@...enic.com>
Subject: Re: Memory allocator semantics

On Tue, Feb 11, 2014 at 03:20:01PM +0200, Pekka Enberg wrote:
> On Tue, Feb 11, 2014 at 2:14 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> > In contrast, from kfree() to a kmalloc() returning some of the kfree()ed
> > memory, I believe the kfree()/kmalloc() implementation must do any needed
> > synchronization and ordering.  But that is a different set of examples,
> > for example, this one:
> >
> >         CPU 0                   CPU 1
> >         p->a = 42;              q = kmalloc(...); /* returning p */
> >         kfree(p);               q->a = 5;
> >                                 BUG_ON(q->a != 5);
> >
> > Unlike the situation with (A), (B), and (C), in this case I believe
> > that it is kfree()'s and kmalloc()'s responsibility to ensure that
> > the BUG_ON() never triggers.
> >
> > Make sense?
> 
> I'm not sure...
> 
> It's the caller's responsibility not to touch "p" after it's handed over to
> kfree() - otherwise that's a "use-after-free" error.  If there's some reordering
> going on here, I'm tempted to blame the caller for lack of locking.

But if the two callers are unrelated, what locking can they possibly use?

>From what I can see, the current implementation prevents the above
BUG_ON() from firing.  If the two CPUs are the same, the CPU will see its
own accesses in order, while if they are different, the implementation
will have had to push the memory through non-CPU-local data structures,
which must have had some heavyweight protection.

							Thanx, Paul

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