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
| ||
|
Date: Wed, 29 Mar 2017 16:56:32 +0100 From: Mark Rutland <mark.rutland@....com> To: Dmitry Vyukov <dvyukov@...gle.com> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, Will Deacon <will.deacon@....com>, Andrey Ryabinin <aryabinin@...tuozzo.com>, kasan-dev <kasan-dev@...glegroups.com>, LKML <linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org> Subject: Re: [PATCH 7/8] asm-generic: add KASAN instrumentation to atomic operations On Wed, Mar 29, 2017 at 05:52:43PM +0200, Dmitry Vyukov wrote: > On Wed, Mar 29, 2017 at 4:00 PM, Mark Rutland <mark.rutland@....com> wrote: > > On Tue, Mar 28, 2017 at 06:15:44PM +0200, Dmitry Vyukov wrote: > >> KASAN uses compiler instrumentation to intercept all memory accesses. > >> But it does not see memory accesses done in assembly code. > >> One notable user of assembly code is atomic operations. Frequently, > >> for example, an atomic reference decrement is the last access to an > >> object and a good candidate for a racy use-after-free. > >> > >> Add manual KASAN checks to atomic operations. > >> > >> Signed-off-by: Dmitry Vyukov <dvyukov@...gle.com> > >> Cc: Mark Rutland <mark.rutland@....com> > >> Cc: Peter Zijlstra <peterz@...radead.org> > >> Cc: Will Deacon <will.deacon@....com>, > >> Cc: Andrew Morton <akpm@...ux-foundation.org>, > >> Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>, > >> Cc: Ingo Molnar <mingo@...hat.com>, > >> Cc: kasan-dev@...glegroups.com > >> Cc: linux-mm@...ck.org > >> Cc: linux-kernel@...r.kernel.org > >> Cc: x86@...nel.org > > > > FWIW, I think that structuring the file this way will make it easier to > > add the {acquire,release,relaxed} variants (as arm64 will need), > > so this looks good to me. > > > > As a heads-up, I wanted to have a go at that, but I wasn't able to apply > > patch two onwards on v4.11-rc{3,4} or next-20170329. I was not able to > > cleanly revert the instrumentation patches currently in next-20170329, > > since other patches built atop of them. > > I based it on git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core Ah; I should have guessed. ;) Thanks for the pointer! I'll give that a go shortly. Thanks, Mark.
Powered by blists - more mailing lists