On Mon, 21 Sep 2020 at 16:31, Will Deacon wrote:
> On Mon, Sep 21, 2020 at 03:26:04PM +0200, Marco Elver wrote:
> > Add architecture specific implementation details for KFENCE and enable
> > KFENCE for the arm64 architecture. In particular, this implements the
> &g
-by: Alexander Potapenko
Signed-off-by: Alexander Potapenko
Signed-off-by: Marco Elver
---
v7:
* Remove dependency on page size [reported by Mark Rutland].
* fault normally on permission faults [reported by Jann Horn].
v5:
* Move generic page allocation code to core.c [suggested by Jann Horn
-developed-by: Marco Elver
Signed-off-by: Marco Elver
Signed-off-by: Alexander Potapenko
---
v7:
* Reports by Jann Horn:
* Comment about is_kfence_address() performance.
* Cleaner CONFIG_KFENCE_STRESS_TEST_FAULTS, using "if EXPERT".
* Fix comment in metadata_to_pageaddr().
need to ensure that the pool uses 4K pages, which is done
using the set_memory_4k() helper function.
Reviewed-by: Dmitry Vyukov
Co-developed-by: Marco Elver
Signed-off-by: Marco Elver
Signed-off-by: Alexander Potapenko
---
v7:
* Only not-present faults should be handled by kfence [reported
nsert KFENCE hooks for SLAB
mm, kfence: insert KFENCE hooks for SLUB
kfence, kasan: make KFENCE compatible with KASAN
Marco Elver (4):
arm64, kfence: enable KFENCE for ARM64
kfence, Documentation: add KFENCE documentation
kfence: add test suite
MAINTAINERS: add entry for KFENCE
-by: Alexander Potapenko
Signed-off-by: Alexander Potapenko
Signed-off-by: Marco Elver
---
v7:
* Reword comments per Jann Horn's suggestions.
v5:
* Add better memory corruption test.
* Test sl*b_def.h primitives.
v4:
* Clarify RCU test comment [reported by Paul E. McKenney].
v3:
* Lower line buffer
-by: Jann Horn
Co-developed-by: Marco Elver
Signed-off-by: Marco Elver
Signed-off-by: Alexander Potapenko
---
v7:
* Remove EXPERT restriction for enabling KASAN+KFENCE. In future, MTE-based
KASAN
without stack traces will benefit from having KFENCE (which has stack
traces). Removing EXPERT
Add entry for KFENCE maintainers.
Reviewed-by: Dmitry Vyukov
Reviewed-by: SeongJae Park
Co-developed-by: Alexander Potapenko
Signed-off-by: Alexander Potapenko
Signed-off-by: Marco Elver
---
v7:
* Add asm/kfence.h [reported by Jann Horn].
v4:
* Split out from first patch.
---
MAINTAINERS
-by: Dmitry Vyukov
Reviewed-by: Jann Horn
Co-developed-by: Marco Elver
Signed-off-by: Marco Elver
Signed-off-by: Alexander Potapenko
---
v7:
* Revert unused orig_size [reported by Jann Horn].
* Add Jann's Reviewed-by.
* Use __kfence_free() where we know is_kfence_address() is true.
* Re-add SLUB
Add KFENCE documentation in dev-tools/kfence.rst, and add to index.
Reviewed-by: Dmitry Vyukov
Co-developed-by: Alexander Potapenko
Signed-off-by: Alexander Potapenko
Signed-off-by: Marco Elver
---
v7:
* Suggestions by Jann Horn:
* Add a note about huge tables.
* Note about graceful
-by: Dmitry Vyukov
Co-developed-by: Marco Elver
Signed-off-by: Marco Elver
Signed-off-by: Alexander Potapenko
---
v7:
* Move kmemleak_free_recursive() before kfence_free() for KFENCE
objects. kmemleak_free_recursive() should be before releasing the
object, to avoid a potential race where
ed).
>
> Signed-off-by: Aleksandr Nogikh
Reviewed-by: Marco Elver
> ---
> v2:
> * Renamed should_fail_lsm_hook() to lsm_hooks_inject_fail().
> ---
> lib/Kconfig.debug | 6 +
> security/security.c | 53 ++---
> 2 files ch
to CONFIG_KCSAN_KUNIT_TEST and
default to KUNIT_ALL_TESTS.
Cc: David Gow
Signed-off-by: Marco Elver
---
kernel/kcsan/Makefile | 4 ++--
kernel/kcsan/{kcsan-test.c => kcsan_test.c} | 2 +-
lib/Kconfig.kcsan | 5 +++--
3 files changed, 6 insertions(+)
reads used,
because on systems with too few CPUs, KUnit allows us to now stop at the
maximum useful threads and not unnecessarily execute redundant test
cases with (the same) limited threads as had been the case before.
Cc: David Gow
Signed-off-by: Marco Elver
---
kernel/kcsan/kcsan_te
+7b99aafdcc2eedea6...@syzkaller.appspotmail.com
Suggested-by: Eric Dumazet
Signed-off-by: Marco Elver
---
net/core/skbuff.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2af12f7e170c..3787093239f5 100644
--- a/net/core
On Fri, 29 Jan 2021 at 19:50, Andrey Konovalov wrote:
>
> KFENCE annotations operate on untagged addresses.
>
> Untag addresses in KASAN runtime where they might be tagged.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
Thank you!
> ---
>
> This can b
On Tue, 26 Jan 2021 at 05:35, David Gow wrote:
>
> On Thu, Jan 14, 2021 at 12:06 AM Marco Elver wrote:
> >
> > Per recently added KUnit style recommendations at
> > Documentation/dev-tools/kunit/style.rst, make the following changes to
> > the KCSAN test:
> >
lection_enabled() is always
> true for generic KASAN. The confusion that this brings outweights saving
> a few instructions.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
alloc caches
> via a new kasan_cache_create_kmalloc() annotation.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> include/linux/kasan.h | 9 +
> mm/kasan/common.c | 18 ++
> mm/slab_common.c | 1 +
> 3 files changed, 24 insertions(+)
to only poison the redzone.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 128cb330ca7
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> For allocations from kmalloc caches, kasan_kmalloc() always follows
> kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
> which is unnecessary.
>
> This patch provides separate implementations for both
On Mon, 14 Dec 2020 at 11:09, Marco Elver wrote:
> On Thu, 10 Dec 2020 at 20:01, Marco Elver wrote:
> > On Thu, 10 Dec 2020 at 18:14, Eric Dumazet wrote:
> > > On Thu, Dec 10, 2020 at 5:51 PM Marco Elver wrote:
> > [...]
> > > > So I started put
> first byte of the memory that's being freed is accessible.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> include/linux/kasan.h | 16
> mm/kasan/common.c | 36 ++--
> 2 files changed, 34 insertions(+)
On Tue, 2 Feb 2021 at 18:16, Andrey Konovalov wrote:
>
> On Tue, Feb 2, 2021 at 5:25 PM Marco Elver wrote:
> >
> > > +#ifdef CONFIG_KASAN_GENERIC
> > > +
> > > +/**
> > > + * kasan_poison_last_granule - mark the last granule of the memory range
On Tue, 2 Feb 2021 at 18:59, Eric Dumazet wrote:
>
> On Mon, Feb 1, 2021 at 5:04 PM Marco Elver wrote:
> >
> > Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when
> > cloning an skb, save and restore truesize after pskb_expand_head(). This
> &
On Tue, 2 Feb 2021 at 19:01, 'Andrey Konovalov' via kasan-dev
wrote:
[...]
> > > @@ -83,6 +83,7 @@ static inline void kasan_disable_current(void) {}
> > > struct kasan_cache {
> > > int alloc_meta_offset;
> > > int free_meta_offset;
> > > + bool is_kmalloc;
[...]
> > > if
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> Currently, krealloc() always calls ksize(), which unpoisons the whole
> object including the redzone. This is inefficient, as kasan_krealloc()
> repoisons the redzone for objects that fit into the same buffer.
>
> This patch changes
each KASAN mode, and check accesses to that granule accordingly.
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> lib/test_kasan.c | 91 ++--
> 1 file changed, 81 insertions(+), 10 deletions(-)
>
> diff --git a/lib/tes
uous, because either way behaviour of
krealloc differs from a kernel with KASAN disabled. Something like
"kasan, mm: fail krealloc on already freed object" perhaps?
> This patch also adds a KASAN-KUnit test to check krealloc() behaviour
> when it's called on a freed object.
>
&
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> Mark all static functions in common.c and kasan.h that are used for
> hardware tag-based KASAN as __always_inline to avoid unnecessary
> function calls.
>
> Signed-off-by: Andrey Konovalov
Does objtool complain about any of these?
gt; kasan_unpoison().
>
> Signed-off-by: Andrey Konovalov
Reviewed-by: Marco Elver
> ---
> mm/kasan/common.c | 9 ++---
> mm/kasan/kasan.h | 33 -
> mm/kasan/shadow.c | 37 ++---
> 3 files changed, 48
On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
>
> On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
>
> > On Mon, May 18, 2020 at 7:34 AM Marco Elver wrote:
> > >
> > > On Mon, 18 May 2020 at 14:44, Marco Elver wrote:
> >
On Tue, 19 May 2020 at 12:16, Marco Elver wrote:
>
> On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
> >
> > On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
> >
> > > On Mon, May 18, 2020 at 7:34 AM Marco Elver wrote:
> > > >
>
may recurse deep enough to cause kernel
reboots without warning.
To prevent similar issues in future, we should disable branch tracing
for the core runtime.
Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/
Reported-by: kernel test robot
Signed-off-by: Marco Elver
---
mm
On Tue, 19 May 2020 at 15:40, Marco Elver wrote:
>
> On Tue, 19 May 2020 at 12:16, Marco Elver wrote:
> >
> > On Mon, 18 May 2020 at 20:05, Marco Elver wrote:
> > >
> > > On Mon, 18 May 2020, 'Nick Desaulniers' via kasan-dev wrote:
> > >
> &
On Tue, 19 May 2020 at 23:10, Qian Cai wrote:
>
> On Tue, May 12, 2020 at 3:09 PM Peter Zijlstra wrote:
> >
> > On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > > ind
On Wed, 20 May 2020 at 05:44, Nathan Chancellor
wrote:
>
> On Tue, May 19, 2020 at 11:16:24PM -0400, Qian Cai wrote:
> > On Tue, May 19, 2020 at 10:47 PM Nathan Chancellor
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
> > > >
> > > >
> > > > > On May 19, 2020,
at 1:36 PM Sedat Dilek
> > > > wrote:
> > > > > On Wed, May 27, 2020 at 1:27 PM Arnd Bergmann wrote:
> > > > > > On Wed, May 27, 2020 at 12:33 PM Marco Elver
> > > > > > wrote:
> > > > > >
> > > > >
On Wed, 27 May 2020 at 15:37, Sedat Dilek wrote:
>
> On Wed, May 27, 2020 at 3:30 PM Marco Elver wrote:
> >
> > On Wed, 27 May 2020 at 15:11, Sedat Dilek wrote:
> > >
> > > On Wed, May 27, 2020 at 2:50 PM Arnd Bergmann wrote:
> > > >
>
On Wed, 27 May 2020 at 21:11, Sedat Dilek wrote:
>
> On Wed, May 27, 2020 at 3:57 PM Marco Elver wrote:
> >
> > On Wed, 27 May 2020 at 15:37, Sedat Dilek wrote:
> > >
> > > On Wed, May 27, 2020 at 3:30 PM Marco Elver wrote:
> > > >
> >
ot too. :-)
>
> /me trims it.
>
> Looks like we need __CHECKER__ ifdeffery somewhere but it is too late
> for me to think straight so tomorrow...
Ouch. The below should be all we need, assuming it's the best we can do
for sparse right now.
Thanks,
-- Marco
-- >8 --
Fr
On Thu, 28 May 2020 at 04:12, Sedat Dilek wrote:
>
[...]
> > > >
> > > > In general, CONFIG_KCSAN=y and the defaults for the other KCSAN
> > > > options should be good. Depending on the size of your system, you
> > > > could also tweak KCSAN runtime performance:
> > > >
On Thu, 28 May 2020 at 17:22, Luc Van Oostenryck
wrote:
>
> On Thu, May 28, 2020 at 09:59:00AM +0200, Marco Elver wrote:
> >
> > Ouch. The below should be all we need, assuming it's the best we can do
> > for sparse right now.
>
> Upstream sparse should be OK with
On Sat, 23 May 2020 at 01:42, Andrew Morton wrote:
>
> On Fri, 22 May 2020 09:52:07 +0200 Marco Elver wrote:
>
> > During early boot, while KASAN is not yet initialized, it is possible to
> > enter reporting code-path and end up in kasan_report(). While
> >
On Mon, 25 May 2020 at 02:37, Paul E. McKenney wrote:
>
> On Sat, May 23, 2020 at 02:23:45PM -0700, Paul E. McKenney wrote:
> > On Sat, May 23, 2020 at 09:05:24PM +0200, Thomas Gleixner wrote:
> > > "Paul E. McKenney" writes:
> > > > On Sat, May 23, 2020 at 11:54:26AM +0200, Thomas Gleixner
On Sun, 31 May 2020 at 11:32, Dmitry Vyukov wrote:
>
> On Fri, May 29, 2020 at 7:11 PM Peter Zijlstra wrote:
> > > Like with KCSAN, we should blanket kill KASAN/UBSAN and friends (at the
> > > very least in arch/x86/) until they get that function attribute stuff
> > > sorted.
> >
> > Something
Instead of __no_kcsan_or_inline, prefer '__no_kcsan inline' in test --
this is in case we decide to remove __no_kcsan_or_inline.
Suggested-by: Peter Zijlstra
Signed-off-by: Marco Elver
---
Hi Paul,
This is to prepare eventual removal of __no_kcsan_or_inline, and avoid a
series that doesn't
On Tue, 26 May 2020 at 14:19, Arnd Bergmann wrote:
>
> On Tue, May 26, 2020 at 2:02 PM Will Deacon wrote:
> > On Tue, May 26, 2020 at 12:42:16PM +0200, Arnd Bergmann wrote:
> > >
> > > I find this patch only solves half the problem: it's much faster than
> > > without the
> > > patch, but still
On Tue, 26 May 2020, Marco Elver wrote:
> On Tue, 26 May 2020 at 14:19, Arnd Bergmann wrote:
> >
> > On Tue, May 26, 2020 at 2:02 PM Will Deacon wrote:
> > > On Tue, May 26, 2020 at 12:42:16PM +0200, Arnd Bergmann wrote:
> > > >
> > > > I find th
On Wed, 27 May 2020 at 09:22, Will Deacon wrote:
>
> On Wed, May 27, 2020 at 01:10:00AM +0200, Arnd Bergmann wrote:
> > On Tue, May 26, 2020 at 9:00 PM Arnd Bergmann wrote:
> > >
> > > On Tue, May 26, 2020 at 7:33 PM 'Marco Elver' via Clang Built Linux
> > &
jcoeqy...@mail.gmail.com
Further compile-testing done with:
gcc 4.8, 4.9, 5.5, 6.4, 7.5, 8.4;
clang 9, 10.
Reported-by: Arnd Bergmann
Signed-off-by: Marco Elver
Cc: Borislav Petkov
Cc: Ingo Molnar
Cc: Nick Desaulniers
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Stephen Rothwell
Cc:
send an almost identical patch, as I
encountered this when using clang.
Reviewed-by: Marco Elver
> mm/kasan/Makefile | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
> index de3121848ddf..bf6f7b1f6b1
On Fri, 29 May 2020 at 19:08, Peter Zijlstra wrote:
[...]
>
> Doesn't this mean we can do the below?
If nobody complains about the lack of __no_kcsan_or_inline, let's do
it. See comments below.
> ---
> Documentation/dev-tools/kcsan.rst | 6 --
> arch/x86/include/asm/bitops.h | 6
C_FLAGS_KASAN_CONFLICT to CC_FLAGS_KASAN_RUNTIME.
Reviewed-by: Marco Elver
Thanks!
> ---
> mm/kasan/Makefile | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
> index de3121848ddf..d532c2587731 1006
On Thu, 4 Jun 2020 at 16:03, Andrey Konovalov wrote:
>
> On Thu, Jun 4, 2020 at 1:09 PM Peter Zijlstra wrote:
> >
> > On Thu, Jun 04, 2020 at 11:50:57AM +0200, Marco Elver wrote:
> > > The KCOV runtime is very minimal, only updating a field in 'current',
> &
to noinstr, and the
checks added in this patch can be guarded by an #ifdef checking if the
compiler has such an attribute or not.
Signed-off-by: Marco Elver
---
Apply after:
https://lkml.kernel.org/r/20200604102241.466509...@infradead.org
v2:
* Rewrite based on Peter's and Andrey's feedback -- v1
For Clang, correctly pass -fno-stack-protector via a separate cc-option,
as -fno-conserve-stack does not exist with Clang.
Signed-off-by: Marco Elver
---
kernel/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/Makefile b/kernel/Makefile
index ce8716a04d0e
extra call from the
fast-path.
In future, our compilers may provide an attribute to implement
__no_sanitize_coverage, which can then be added to noinstr, and the
checks added in this patch can be guarded by an #ifdef checking if the
compiler has such an attribute or not.
Signed-off-by: Marco Elver
-option, we were missing
-fno-stack-protector with Clang. Unconditionally adding this option
fixes this for Clang.
Suggested-by: Nick Desaulniers
Signed-off-by: Marco Elver
---
v3:
* Do not wrap -fno-stack-protector in cc-option, since all KCOV-supported
compilers support the option as pointed out
]
[ 17.928206] this frame has 2 objects:
[ 17.928783] [32, 36) 'i'
[ 17.928784] [96, 106) 'stack_array'
[ 17.929216]
[ 17.930031] Memory state around the buggy address:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198435
Signed-off-by: Marco Elver
---
Changes since V1:
- Fix types
On Tue, 21 May 2019 at 17:53, Alexander Potapenko wrote:
>
> On Tue, May 21, 2019 at 5:43 PM Andrey Ryabinin
> wrote:
> >
> > On 5/20/19 6:47 PM, Marco Elver wrote:
> >
> > > +static void print_decoded_frame_descr(const char *frame_descr)
> > > +{
&
]
[ 17.928206] this frame has 2 objects:
[ 17.928783] [32, 36) 'i'
[ 17.928784] [96, 106) 'stack_array'
[ 17.929216]
[ 17.930031] Memory state around the buggy address:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198435
Signed-off-by: Marco Elver
---
Changes since v2:
- Comment about why
you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v5.1 next-20190517]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
Coffee Lake seems to work like Skylake and Kaby Lake. This patch adds all
device IDs for Coffee Lake-S CPUs according to datasheet.
Cc: Jason Baron
Cc: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: Tony Luck
Cc: linux-edac
---
Tested with a Xeon E-2124G.
---
drivers/edac/ie31200_edac.c |
On Mon, 10 Jun 2019 at 20:01, Luck, Tony wrote:
>
> On Sun, Jun 09, 2019 at 05:16:13PM +0200, Marco Elver wrote:
>
> Marco,
>
> Thanks for the patch. One comment below.
>
> > - {
> > - PCI_VEND_DEV(INTEL, IE31200_HB_1), PCI_ANY_ID, PCI_ANY_ID, 0,
Reformat device table after Coffee Lake additions to be more readable.
No functional change.
Signed-off-by: Marco Elver
Cc: Jason Baron
Cc: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: Tony Luck
Cc: linux-edac
---
drivers/edac/ie31200_edac.c | 80 ++---
1
Coffee Lake seems to work like Skylake and Kaby Lake. This patch adds all
device IDs for Coffee Lake-S CPUs according to datasheet.
Signed-off-by: Marco Elver
Cc: Jason Baron
Cc: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: Tony Luck
Cc: linux-edac
---
v2:
- Reverted formatting existing
__kasan_check_read() is
chosen to check validity of an object inside ksize().
Previous version:
http://lkml.kernel.org/r/20190624110532.41065-1-el...@google.com
v2:
* Complete rewrite of patch, refactoring ksize() and relying on
kasan_check_read for validation.
Marco Elver (4):
mm/kasan
This refactors common code of ksize() between the various allocators
into slab_common.c: __ksize() is the allocator-specific implementation
without instrumentation, whereas ksize() includes the required KASAN
logic.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander
.
This change eliminates the need for the __KASAN_INTERNAL definition.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: kasan
://bugzilla.kernel.org/show_bug.cgi?id=199359
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: kasan-...@googlegroups.com
Cc: linux-kernel
Adds a simple test that checks if double-kzfree is being detected
correctly.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc
This version addresses formatting in kasan-checks.h and splits
introduction of __kasan_check and returning boolean into 2 patches.
Previous version:
http://lkml.kernel.org/r/20190626122018.171606-1-el...@google.com
Marco Elver (5):
mm/kasan: Introduce __kasan_check_{read,write}
mm/kasan
This introduces __kasan_check_{read,write}. __kasan_check functions may
be used from anywhere, even compilation units that disable
instrumentation selectively.
This change eliminates the need for the __KASAN_INTERNAL definition.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
This changes {,__}kasan_check_{read,write} functions to return a boolean
denoting if the access was valid or not.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc
Adds a simple test that checks if double-kzfree is being detected
correctly.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Mark
This refactors common code of ksize() between the various allocators
into slab_common.c: __ksize() is the allocator-specific implementation
without instrumentation, whereas ksize() includes the required KASAN
logic.
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander
://bugzilla.kernel.org/show_bug.cgi?id=199359
Signed-off-by: Marco Elver
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Mark Rutland
Cc: kasan-...@googlegroups.com
Cc
On Wed, 29 May 2019 at 12:01, Peter Zijlstra wrote:
>
> On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > For the default, we decided to err on the conservative side for now,
> > since it seems that e.g. x86 operates only on the byte the bit is on.
>
>
Adds a simple stack overflow test, to check the error being reported on
an overflow. Without CONFIG_STACK_GUARD_PAGE, the result is typically
some seemingly unrelated KASAN error message due to accessing random
other memory.
Signed-off-by: Marco Elver
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc
considered -- any comments on
better alternatives or improvements are welcome.
Signed-off-by: Marco Elver
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Mark Rutland
Hi Daniel,
On Tue, 1 Oct 2019 at 16:50, Daniel Axtens wrote:
>
> Hi Marco,
>
> > We would like to share a new data-race detector for the Linux kernel:
> > Kernel Concurrency Sanitizer (KCSAN) --
> > https://github.com/google/ktsan/wiki/KCSAN (Details:
> >
Hi Joel,
On Tue, 1 Oct 2019 at 23:19, Joel Fernandes wrote:
>
> On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > Hi all,
> >
> > We would like to share a new data-race detector for the Linux kernel:
> > Kernel Concurrency Sanitizer (KCSAN) --
>
Hi all,
We would like to share a new data-race detector for the Linux kernel:
Kernel Concurrency Sanitizer (KCSAN) --
https://github.com/google/ktsan/wiki/KCSAN (Details:
https://github.com/google/ktsan/blob/kcsan/Documentation/dev-tools/kcsan.rst)
To those of you who we mentioned at LPC that
On Fri, 20 Sep 2019 at 18:47, Dmitry Vyukov wrote:
>
> On Fri, Sep 20, 2019 at 6:31 PM Mark Rutland wrote:
> >
> > On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > > We would like to share a new data-race detector for the Linux kernel:
> > >
On Fri, 20 Sep 2019 at 17:54, Will Deacon wrote:
>
> Hi Marco,
>
> On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > We would like to share a new data-race detector for the Linux kernel:
> > Kernel Concurrency Sanitizer (KCSAN) --
> > https://gith
On Thu, 3 Oct 2019 at 18:12, Mark Rutland wrote:
>
> On Fri, Sep 20, 2019 at 07:51:04PM +0200, Marco Elver wrote:
> > On Fri, 20 Sep 2019 at 18:47, Dmitry Vyukov wrote:
> > >
> > > On Fri, Sep 20, 2019 at 6:31 PM Mark Rutland wrote:
> > > >
> &
On Sat, 5 Oct 2019 at 13:28, Christian Brauner
wrote:
>
> When assiging and testing taskstats in taskstats
> taskstats_exit() there's a race around writing and reading sig->stats.
>
> cpu0:
> task calls exit()
> do_exit()
> -> taskstats_exit()
> -> taskstats_tgid_alloc()
>
On Sat, 5 Oct 2019 at 16:15, Christian Brauner
wrote:
>
> On Sat, Oct 05, 2019 at 03:33:07PM +0200, Marco Elver wrote:
> > On Sat, 5 Oct 2019 at 13:28, Christian Brauner
> > wrote:
> > >
> > > When assiging and testing taskstats in taskstats
> > > t
kernel/stop_machine.c:516
> | smpboot_thread_fn+0x1a8/0x300 kernel/smpboot.c:165
> | kthread+0x1b5/0x200 kernel/kthread.c:255
> | ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:352
> |
> | Reported by Kernel Concurrency Sanitizer on:
> | CPU: 7 PID: 44 Comm: migration/7 Not t
using "mask_ofl_test" for recording and
> > "mask_ofl_ipi" for iteration. This would improve the readibility of the
> > IPI sending loop in sync_rcu_exp_select_node_cpus().
> >
> > Signed-off-by: Boqun Feng
> > ---
>
> Reviewed-by: Joel Fernandes
taskstats: cleanup ->signal->stats allocation")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christian Brauner
> Reviewed-by: Dmitry Vyukov
> ---
> /* v1 */
> Link:
> https://lore.kernel.org/r/20191005112806.13960-1-christian.brau...@ubuntu.com
>
> /* v2 */
>
), BIOS 1.12.0-1 04/01/2014
Workqueue: kblockd blk_mq_run_work_fn
==
Signed-off-by: Marco Elver
Cc: Paul E. McKenney
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
Cc: Ingo Molnar
Cc
Hi,
On Thu, 17 Oct 2019 at 14:36, syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:d724f94f x86, kcsan: Enable KCSAN for x86
> git tree: https://github.com/google/ktsan.git kcsan
> console output: https://syzkaller.appspot.com/x/log.txt?x=17884db360
On Thu, 17 Oct 2019 at 20:17, Alexey Dobriyan wrote:
>
> On Thu, Oct 17, 2019 at 02:56:47PM +0200, Marco Elver wrote:
> > Hi,
> >
> > On Thu, 17 Oct 2019 at 14:36, syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot foun
On Fri, 1 May 2020 at 10:35, Anders Roxell wrote:
>
> Make it easier to enable all KUnit fragments. This is needed for kernel
> test-systems, so its easy to get all KUnit tests enabled and if new gets
> added they will be enabled as well. Fragments that has to be builtin
> will be missed if
Hi Mark,
Thanks for you comments; see inline comments below.
On Tue, 22 Oct 2019 at 16:11, Mark Rutland wrote:
>
> Hi Marco,
>
> On Thu, Oct 17, 2019 at 04:12:58PM +0200, Marco Elver wrote:
> > Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for
>
On Mon, 14 Oct 2019 at 10:40, Dmitry Vyukov wrote:
>
> On Mon, Oct 14, 2019 at 7:11 AM wrote:
> >
> > Hi Dmitry,
> >
> > I am from Qualcomm Linux Security Team, just going through KCSAN and found
> > that there was a thread for arm64 support
> > (https://lkml.org/lkml/2019/9/20/804).
> >
> >
Hi Sachin,
My plan was to send patches upstream within the month.
Thanks,
-- Marco
On Mon, 14 Oct 2019 at 11:30, wrote:
>
> Hi Marco,
>
> When can we expect upstream of KCSAN on kernel mainline. Any timeline?
>
> Regards,
> Sachin Grover
>
> -Original Messa
On Mon, 14 Oct 2019 at 20:00, Joel Fernandes wrote:
>
> On Wed, Oct 09, 2019 at 05:57:43PM +0200, Marco Elver wrote:
> > This fixes a data-race where `atomic_t dynticks` is copied by value. The
> > copy is performed non-atomically, resulting in a data-race if `dyntic
401 - 500 of 1015 matches
Mail list logo
