On Thu, Jan 4, 2024 at 9:45 PM Stefan Hajnoczi wrote:
>
> On Tue, Jan 02, 2024 at 08:03:46AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 01, 2024 at 05:38:24AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:fbafc3e621c3 Merge
son_memory() calls for the output buffers.
> The logic is the same as in [1].
>
> [1]
> https://github.com/zlib-ng/zlib-ng/commit/1f5ddcc009ac3511e99fc88736a9e1a6381168c5
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
>
ask
> variable. Disable instrumentation in the respective functions. They are
> very small and it's easy to see that no important metadata updates are
> lost because of this.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
Leoshkevich
Reviewed-by: Alexander Potapenko
ison the whole dest manually with kmsan_unpoison_memory().
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:06 PM Ilya Leoshkevich wrote:
>
> Like for KASAN, it's useful to temporarily disable KMSAN checks around,
> e.g., redzone accesses. Introduce kmsan_disable_current() and
> kmsan_enable_current(), which are similar to their KASAN counterparts.
Initially we used to have
depending on whether the code is built with
> sanitizers or fortify. This should probably be streamlined, but in the
> meantime resolve the issues by introducing the IN_BOOT_STRING_C macro,
> similar to the existing IN_ARCH_STRING_C macro.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:03 PM Ilya Leoshkevich wrote:
>
> put_user() uses inline assembly with precise constraints, so Clang is
> in principle capable of instrumenting it automatically. Unfortunately,
> one of the constraints contains a dereferenced user pointer, and Clang
> does not currently
ce this question came up, I should probably add a check and
> a WARN_ON_ONCE() here.
Yes, please.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Prevent KMSAN from complaining about buffers filled by cpacf_trng()
> being uninitialized.
>
> Tested-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> +static inline void *arch_kmsan_get_meta_or_null(void *addr, bool is_origin)
> +{
> + if (addr >= (void *)_lowcore &&
> + addr < (void *)(_lowcore + 1)) {
> + /*
> +* Different lowcores accessed via S390_lowcore are described
> +* by
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(hope some s390 maintainer acks this as well)
> +static inline void *kmsan_get_metadata(void *addr, bool is_origin)
> +{
> + return NULL;
> +}
> +
> #endif
We shouldn't need this part, as kmsan_get_metadata() should never be
called in non-KMSAN builds.
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Comparing pointers with TASK_SIZE does not make sense when kernel and
> userspace overlap. Skip the comparison when this is the case.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
an_unpoison_memory()
> definition. This produces some runtime overhead, but only when building
> with CONFIG_KMSAN. The benefit is that it does not disturb the existing
> KMSAN build logic and call sites don't need to be changed.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> It is useful to manually copy metadata in order to describe the effects
> of memmove()-like logic in uninstrumented code or inline asm. Introduce
> kmsan_memmove_metadata() for this purpose.
>
> Signed-off-by: Ilya Leoshkevich
> ---
>
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Currently KMSAN does not fully propagate metadata in strlcpy() and
> strlcat(), because they are built with -ffreestanding and call
> memcpy(). In this combination memcpy() calls are not instrumented.
Is this something specific to
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> The inline assembly block in s390's chsc() stores that much.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> A problem with __memset() is that, at least for me, it always ends
> up being a call. There is a use case where we need to write only 1
> byte, so I thought that introducing a call there (when compiling
> without KMSAN) would be unacceptable.
Wonder what happens with that use case if we e.g.
On Fri, Dec 8, 2023 at 3:14 PM Ilya Leoshkevich wrote:
>
> On Fri, 2023-12-08 at 14:32 +0100, Alexander Potapenko wrote:
> > On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich
> > wrote:
> > >
> > > The constraints of the DFLTCC inline assembly are not pr
gs when running the ftrace testsuite.
>
> Fix by trusting the assembly code and always unpoisoning ftrace_regs in
> kprobe_ftrace_handler().
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
gs when running the ftrace testsuite.
I couldn't reproduce these warnings on x86, hope you really need this
change on s390 :)
> Fix by trusting the architecture-specific assembly code and always
> unpoisoning ftrace_regs in ftrace_ops_list_func.
>
> Signed-off-by: Ilya Leoshkev
On Fri, Dec 8, 2023 at 1:53 PM Alexander Potapenko wrote:
>
> On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
> >
> > KMSAN warns about check_canary() accessing the canary.
> >
> > The reason is that, even though set_canary() is properly instrumented
> &
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Avoid false KMSAN negatives with SLUB_DEBUG by allowing
> kmsan_slab_free() to poison the freed memory, and by preventing
> init_object() from unpoisoning new allocations. The usage of
> memset_no_sanitize_memory() does not degrade the
On Tue, Nov 21, 2023 at 11:06 PM Ilya Leoshkevich wrote:
>
> Add a wrapper for memset() that prevents unpoisoning.
We have __memset() already, won't it work for this case?
On the other hand, I am not sure you want to preserve the redzone in
its previous state (unless it's known to be poisoned).
-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> The constraints of the DFLTCC inline assembly are not precise: they
> do not communicate the size of the output buffers to the compiler, so
> it cannot automatically instrument it.
KMSAN usually does a poor job instrumenting inline
s.
>
> Unpoisoning the canary is not the right thing to do: only
> check_canary() is supposed to ever touch it. Instead, disable KMSAN
> checks around canary read accesses.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
Hi Ilya,
Sorry for this taking so long, I'll probably take a closer look next week.
Overall, the s390 part looks good to me, but I wanted to check the x86
behavior once again (and perhaps figure out how to avoid introducing
another way to disable KMSAN).
Do you happen to have a Git repo with your
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> This is normally done by the generic entry code, but the
> kernel_stack_overflow() flow bypasses it.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> ---
> arch/s390/kernel/traps.c | 2 ++
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> The pages for the KMSAN metadata associated with most kernel mappings
> are taken from memblock by the common code. However, vmalloc and module
> metadata needs to be defined by the architectures.
>
> Be a little bit more careful than
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Avoid false KMSAN negatives with SLUB_DEBUG by allowing
> kmsan_slab_free() to poison the freed memory, and by preventing
> init_object() from unpoisoning new allocations.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> mm/kmsan/hooks.c |
ata for page operations")
> Suggested-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> ---
> mm/kmsan/shadow.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
> index b9d05aff313e..2
option to describe this situation, so explicitly check for
> s390.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see the nit below)
> ---
> mm/kmsan/init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kmsan/init.c b/mm/kmsan
Leoshkevich
Reviewed-by: Alexander Potapenko
ts.
Good catch, thank you!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
viewed-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
stens
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see the comment below)
>
> -#include
> +#include
For the sake of consistency with other KMSAN code, please keep the
headers sorted alphabetically.
MSAN for now.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
.
Nice!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> All other sanitizers are disabled for these components as well.
>
> Reviewed-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see a nit below)
> ---
> arch/s390/boot/
to improve the KMSAN usability for
> modules.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Thu, Nov 16, 2023 at 10:04 AM Alexander Potapenko wrote:
>
> On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
> >
> > The unwind code can read uninitialized frames. Furthermore, even in
> > the good case, KMSAN does not emit shadow for backchain
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> The unwind code can read uninitialized frames. Furthermore, even in
> the good case, KMSAN does not emit shadow for backchains. Therefore
> disable it for the unwinding functions.
>
> Signed-off-by: Ilya Leoshkevich
> ---
>
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Like for KASAN, it's useful to temporarily disable KMSAN checks around,
> e.g., redzone accesses.
This example is incorrect, because KMSAN does not have redzones.
You are calling these functions from "mm: slub: Let KMSAN access
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Hi,
>
> This series provides the minimal support for Kernel Memory Sanitizer on
> s390. Kernel Memory Sanitizer is clang-only instrumentation for finding
> accesses to uninitialized memory. The clang support for s390 has already
> been
" case, since the allocation
> is ephemeral for the lifespan of the namespace, there are no explicit
> restriction. However, the implicit restriction, of having enough
> available "System RAM" to store the page map for the typically large
> pmem, still applies.
>
> Fixes: 6
bling preemption around flush_tlb_one_kernel().
>
> Link: https://lore.kernel.org/lkml/ygidbaboelggm...@elver.google.com/
> Reported-by: Tomi Sarvela
> Signed-off-by: Marco Elver
Acked-by: Alexander Potapenko
prevent certain information leaks.
>
> Signed-off-by: Marco Elver
Acked-by: Alexander Potapenko
> ---
> mm/kfence/core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 3b8ec938470a..f7106f28443d 100644
> --- a
On Fri, Mar 5, 2021 at 2:31 AM Andrew Morton wrote:
>
> On Thu, 4 Mar 2021 22:05:48 +0100 Alexander Potapenko
> wrote:
>
> > On Thu, Mar 4, 2021 at 9:53 PM Marco Elver wrote:
> > >
> > > cache_alloc_debugcheck_after() performs checks on an object, including
On Thu, Mar 4, 2021 at 9:53 PM Marco Elver wrote:
>
> cache_alloc_debugcheck_after() performs checks on an object, including
> adjusting the returned pointer. None of this should apply to KFENCE
> objects. While for non-bulk allocations, the checks are skipped when we
> allocate via KFENCE, for
On Wed, Mar 3, 2021 at 1:12 PM Marco Elver wrote:
>
> Use %td for ptrdiff_t.
>
> Link:
> https://lkml.kernel.org/r/3abbe4c9-16ad-c168-a90f-087978ccd...@csgroup.eu
> Reported-by: Christophe Leroy
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
> [ 14.998426] BUG: KFENCE: invalid read in
> finish_task_switch.isra.0+0x54/0x23c
> [ 14.998426]
> [ 15.007061] Invalid read at 0x(ptrval):
> [ 15.010906] finish_task_switch.isra.0+0x54/0x23c
> [ 15.015633] kunit_try_run_case+0x5c/0xd0
> [ 15.019682]
gt; also avoids scanning the whole source string.
Looks like a good thing to do.
> Signed-off-by: Zhiyuan Dai
Acked-by: Alexander Potapenko
> ---
> mm/kasan/report_generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kasan/report_generic.c b/
On Mon, Jan 18, 2021 at 11:54 PM Randy Dunlap wrote:
>
> On 1/18/21 1:56 AM, vji...@codeaurora.org wrote:
> > From: Yogesh Lal
> >
> > Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE.
> >
> > Aim is to have configurable value for STACK_HASH_SIZE,
> > so depend on use case one can
> Signed-off-by: Vijayanand Jitta
Reviewed-by: Alexander Potapenko
> ---
> lib/Kconfig | 9 +
> lib/stackdepot.c | 3 +--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index b46a9fd..96ee125 100644
> --- a/
Thank you all for the comments!
Since concerns have been raised that another error reporting system
may quickly go out of control, we've decided to not pursue this
solution any further.
Instead, we will try to rely on existing ftrace mechanisms to deliver
notifications to the userspace, and
On Fri, Jan 15, 2021 at 2:09 PM Alexander Potapenko wrote:
>
> On Fri, Jan 15, 2021 at 2:06 PM Vlastimil Babka wrote:
> >
> > Should have CCd linux-api@, please do next time
> Thanks, will do!
> Shall I also CC the v2 ABI patch explicitly?
I'll be dropping the sysfs ch
> > > +
> > > + /* Pairs with acquire in last_report_show(). */
> > > + atomic_inc_return_release(_reports);
> > > + schedule_delayed_work(_done, 0);
> >
> > Why delayed work when it gets queued immediately?
>
> Because error reports may be sent from a place where waiting is
>
On Mon, Jan 18, 2021 at 12:38 PM Petr Mladek wrote:
Thanks for your input! Some responses below.
>
> On Fri 2021-01-15 14:03:33, Alexander Potapenko wrote:
> > With the introduction of various production error-detection tools, such as
> > MTE-based KASAN and KFENC
On Mon, Jan 18, 2021 at 10:22 AM Marco Elver wrote:
>
> Add missing copyright header to KFENCE documentation.
>
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
On Mon, Jan 18, 2021 at 10:22 AM Marco Elver wrote:
>
> Add missing copyright and description header to KFENCE source file.
>
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
On Mon, Jan 18, 2021 at 10:22 AM Marco Elver wrote:
>
> Add missing copyright and description headers to KFENCE source files.
>
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> If appropriate, to be squashed into:
>
> mm: add Kernel Elect
On Mon, Jan 18, 2021 at 10:22 AM Marco Elver wrote:
>
> Add missing copyright and description header to KFENCE source file.
>
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
planning to do.
Also, shall I rename the library/config/etc. accordingly (to e.g.
CONFIG_KERNEL_WARN_NOTIFY)?
> Use the function in kernel/trace/trace.c: tracer_init_tracefs() to add that
> directory. That's for files in the tracefs directory that will not be
> duplicated by instances.
On Fri, Jan 15, 2021 at 2:50 PM Greg KH wrote:
>
> Minor comments, if in the future, you really do want to mess around in sysfs:
>
Thanks! Guess most of these comments apply even if I choose another FS
to mess around with.
> No copyright notice for the file? While acceptable, odds are your
>
t
didn't change under their feet.
> Also, any reason you didn't cc: the sysfs maintainers?
Only my lack of common sense :)
I'll add them should the following patches rely on sysfs, thank you!
Alex
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 Mün
gned-off-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
ooglesource.com/id/I8fb3c06d49671305ee184175a39591bc26647a67
> > Signed-off-by: Andrey Konovalov
>
> Much nicer!
>
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
_RET_IP_ to __kasan_check_byte().
> >
> > Also add a new ksize_uaf() test that checks that a use-after-free is
> > detected via ksize() itself, and via plain accesses that happen later.
> >
> > Link:
> > https://linux-review.googlesource.com/id/Iaabf771881d0f9ce1b969f2a62938e99d3308ec5
> > Signed-off-by: Andrey Konovalov
>
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
ttps://linux-review.googlesource.com/id/I2a8bf797aecf81baeac61380c567308f319e263d
> > Signed-off-by: Andrey Konovalov
>
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
(see a nit below)
> > + cache = kmem_cache_create("test_cache", size, 0, 0, NULL)
s://linux-review.googlesource.com/id/I6447af436a69a94bfc35477f6bf4e2122948355e
> > Signed-off-by: Andrey Konovalov
>
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
gt;
> Note, that test #3 causes a significant number (255) of KASAN reports
> to be printed during execution for the SW_TAGS mode.
>
> Link:
> https://linux-review.googlesource.com/id/I78f1375efafa162b37f3abcb2c5bc2f3955dfd8e
> Reviewed-by: Marco Elver
> Signed-off-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
On Thu, Jan 14, 2021 at 8:36 PM Andrey Konovalov wrote:
>
> Clarify and update comments in KASAN tests.
>
> Link:
> https://linux-review.googlesource.com/id/I6c816c51fa1e0eb7aa3dead6bda1f339d2af46c8
> Reviewed-by: Marco Elver
> Signed-off-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
On Fri, Jan 15, 2021 at 2:06 PM Vlastimil Babka wrote:
>
> Should have CCd linux-api@, please do next time
Thanks, will do!
Shall I also CC the v2 ABI patch explicitly?
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
v2:
- change error_report_start and error_report_end prototypes
to accept enum error_detector instead of char*
(as suggested by Steven Rostedt)
---
mm/kfence/report.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
v2:
- change error_report_start and error_report_end prototypes
to accept enum error_detector instead of char*
(as suggested by Steven Rostedt)
---
mm/kasan/report.c | 15 +--
1 file changed, 9 insertions(+), 6
-by: Alexander Potapenko
---
v2: - change error_report_start and error_report_end prototypes
to accept enum error_detector instead of char*
(as suggested by Steven Rostedt)
---
include/trace/events/error_report.h | 84 +
kernel/trace/Makefile
-error_report
new file mode 100644
index ..666d039f93a9
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-error_report
@@ -0,0 +1,41 @@
+What: /sys/kernel/error_report/
+Date: January 2021
+Contact: Alexander Potapenko ,
+ Marco Elver
: Petr Mladek
Cc: Steven Rostedt
Cc: Sergey Senozhatsky
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
v2:
- s/memory error reports/error reports from debugging tools/
(per Andrew Morton's comment)
- change error_report_start and error_report_end prototypes
to accept enum
to use this new feature.
v2:
- added ABI documentation for /sys/kernel/error_report/
- changed error_report_start and error_report end tracepoints to take
a fixed set of values for the error detector
Alexander Potapenko (5):
tracing: add error_report trace points
lib: add
On Thu, Jan 14, 2021 at 3:52 PM Steven Rostedt wrote:
>
> On Thu, 14 Jan 2021 08:49:57 +0100
> Alexander Potapenko wrote:
>
> > We'll need to explicitly list the enum values once again in
> > __print_symbolic(), right? E.g.:
> >
> > enum debug
On Thu, Jan 14, 2021 at 10:51 AM Alexander Potapenko wrote:
>
> On Thu, Jan 14, 2021 at 1:06 AM Andrew Morton
> wrote:
> >
> > On Wed, 13 Jan 2021 10:16:55 +0100 Alexander Potapenko
> > wrote:
> >
> > > With the introduction of various production erro
On Thu, Jan 14, 2021 at 1:06 AM Andrew Morton wrote:
>
> On Wed, 13 Jan 2021 10:16:55 +0100 Alexander Potapenko
> wrote:
>
> > With the introduction of various production error-detection tools, such as
> > MTE-based KASAN and KFENCE, the need arises to efficiently not
On Wed, Jan 13, 2021 at 10:10 PM Steven Rostedt wrote:
>
> On Wed, 13 Jan 2021 10:16:54 +0100
> Alexander Potapenko wrote:
>
> > +DECLARE_EVENT_CLASS(error_report_template,
> > + TP_PROTO(const char *error_detector, unsigned long id),
>
> Ins
ros and use them.
> >
> > Link:
> > https://linux-review.googlesource.com/id/I237484a7fddfedf4a4aae9cc61ecbcdbe85a0a63
> > Suggested-by: Alexander Potapenko
> > Signed-off-by: Andrey Konovalov
>
> Nice!
>
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
58ef2804ff465d8eb07434a300bf36388d55
> Signed-off-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
> ---
> lib/test_kasan.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index 283feda9882a..a1a35d75ee1e 100644
>
On Tue, Jan 12, 2021 at 9:07 PM 'Andrey Konovalov' via kasan-dev
wrote:
>
> On Tue, Jan 12, 2021 at 9:30 AM Alexander Potapenko wrote:
> >
> > On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov
> > wrote:
> > >
> > > Since the hardware tag
-by: Alexander Potapenko
---
include/trace/events/error_report.h | 51 +
kernel/trace/Makefile | 1 +
kernel/trace/error_report-traces.c | 11 +++
3 files changed, 63 insertions(+)
create mode 100644 include/trace/events/error_report.h
create mode
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
mm/kasan/report.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index c0fb21797550..fd015dd5dd39 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
: Petr Mladek
Cc: Steven Rostedt
Cc: Sergey Senozhatsky
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
lib/Kconfig.debug | 14 ++
lib/Makefile | 2 +
lib/error_report_notify.c | 278 ++
3 files changed, 294 insertions
Cc: linux...@kvack.org
Signed-off-by: Alexander Potapenko
---
mm/kfence/report.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/kfence/report.c b/mm/kfence/report.c
index 4dedc2ff8f28..5c063b5b2227 100644
--- a/mm/kfence/report.c
+++ b/mm/kfence/report.c
@@ -9,6 +9,7 @@
#include
to use this new feature.
Alexander Potapenko (4):
tracing: add error_report trace points
lib: add error_report_notify to collect debugging tools' reports
kfence: use error_report_start and error_report_end tracepoints
kasan: use error_report_start and error_report_end tracepoints
include
ink:
> https://linux-review.googlesource.com/id/Ia173d5a1b215fe6b2548d814ef0f4433cf983570
Reviewed-by: Alexander Potapenko
On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov wrote:
>
> Since the hardware tag-based KASAN mode might not have a redzone that
> comes after an allocated object (when kasan.mode=prod is enabled), the
> kasan_bitops_tags() test ends up corrupting the next object in memory.
>
> Change the test so
Nit: s/adopt/adapt in the title.
> +again:
> ptr1 = kmalloc(size, GFP_KERNEL);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr1);
>
> @@ -384,6 +386,13 @@ static void kmalloc_uaf2(struct kunit *test)
> ptr2 = kmalloc(size, GFP_KERNEL);
>
On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov wrote:
>
> It might not be obvious to the compiler that the expression must be
> executed between writing and reading to fail_data. In this case, the
> compiler might reorder or optimize away some of the accesses, and
> the tests will fail.
Have
view.googlesource.com/id/Id347dfa5fe8788b7a1a189863e039f409da0ae5f
Reviewed-by: Alexander Potapenko
> KASAN tests consist on two parts:
While at it: "consist of".
On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov wrote:
>
> Add 3 new tests for tag-based KASAN modes:
>
> 1. Check that match-all pointer tag is not assigned randomly.
> 2. Check that 0xff works as a match-all pointer tag.
> 3. Check that there are no match-all memory tags.
>
> Note, that test #3
On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov wrote:
>
> Clarify and update comments and info messages in KASAN tests.
>
> Signed-off-by: Andrey Konovalov
> Link:
> https://linux-review.googlesource.com/id/I6c816c51fa1e0eb7aa3dead6bda1f339d2af46c8
> void *kasan_ptr_result;
> int
1 - 100 of 1004 matches
Mail list logo
