>
> Michan, We would still need config option so that we can reduce the
> memory consumption on low ram devices using config.
>
> Alex, On this,
> "I also suppose device vendors may prefer setting a fixed (maybe
> non-default) hash size for low-memory devices rather than letting the
> admins
t; Signed-off-by: Marco Elver
Acked-by: Alexander Potapenko
> > ---
> > mm/kfence/kfence_test.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/kfence/kfence_test.c b/mm/kfence/kfence_test.c
> > index 1433a35a1644..f
On Mon, Dec 14, 2020 at 5:02 AM Vijayanand Jitta wrote:
>
>
>
> On 12/11/2020 6:55 PM, Alexander Potapenko wrote:
> > On Fri, Dec 11, 2020 at 1:45 PM Vijayanand Jitta
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2020 2:06 PM, Alexander P
On Wed, Dec 16, 2020 at 4:43 AM Vijayanand Jitta wrote:
>
>
>
> On 12/14/2020 4:02 PM, Vijayanand Jitta wrote:
> >
> >
> > On 12/14/2020 3:04 PM, Alexander Potapenko wrote:
> >> On Mon, Dec 14, 2020 at 5:02 AM Vijayanand Jitta
> >> wrote:
> >
On Wed, Dec 16, 2020 at 2:06 PM Vijayanand Jitta wrote:
>
>
>
> On 12/16/2020 1:56 PM, Alexander Potapenko wrote:
> > On Wed, Dec 16, 2020 at 4:43 AM Vijayanand Jitta
> > wrote:
> >>
> >>
> >>
> >> On 12/14/2020 4:02 PM, Vijayanand Jit
t;>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >>>>>>> member
> > Can you provide an example of a use case in which the user wants to
> > use the stack depot of a smaller size without disabling it completely,
> > and that size cannot be configured statically?
> > As far as I understand, for the page owner example you gave it's
> > sufficient to provide a
From: Albert van der Linde
To test fault-tolerance of user memory acceses in x86, add support for
fault injection.
Make both put_user() and get_user() fail with -EFAULT, and clear_user()
fail by not clearing any bytes.
Reviewed-by: Akinobu Mita
Reviewed-by: Alexander Potapenko
Signed-off
(Albert's @google.com address is gone, removing it from CC list)
On Fri, Oct 23, 2020 at 10:16 AM Alexander Potapenko wrote:
>
> From: Albert van der Linde
>
> To test fault-tolerance of user memory acceses in x86, add support for
> fault injection.
>
> Make both put_user(
DEBUG_FS is enabled).
>
> Signed-off-by: Aleksandr Nogikh
> Reviewed-by: Marco Elver
> Reviewed-by: Tetsuo Handa
> Reviewed-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
> ---
> v4:
> - Changed retval debugfs file type - now it keeps a signed integer.
> - Made CON
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: If0a2690042a2aa0fca70cea601ae9aabe72fa233
> ---
> mm/kasan/common.c | 5 -
> mm/kasan/generic.c| 5 -
> mm/kasan/generic_report.c | 5 -
> mm/kasan/init.c
On Tue, Nov 10, 2020 at 11:11 PM Andrey Konovalov wrote:
>
> Currently only generic KASAN mode supports vmalloc, reflect that
> in the config.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenk
mm/kasan/common.c.
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: Ie20b6c689203cd6de4fd7f2c465ec081c00c5f15
> ---
> include/linux/
ing software modes.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I864be75a88b91b443c55e9c2042865e157
an_unpoison_shadow to kasan_unpoison_memory,
> and kasan_poison_shadow to kasan_poison_memory.
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-
ANULE_SIZE, and KASAN_SHADOW_MASK
> to KASAN_GRANULE_MASK.
>
> Also use MASK when used as a mask, otherwise use SIZE.
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
code for software modes.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I8d68c47345afc1dbedadde738f34a874dcae5080
> --
abled for software KASAN modes that use
> shadow memory.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: Ic1c32ce72d464
N_DOWN(free_region_end, KASAN_GRANULE_PAGE);
>
> if (end != region_end &&
> free_region_end > region_end)
> - region_end += PAGE_SIZE * KASAN_GRANULE_SIZE;
> + region_end += KASAN_GRANULE_PAGE;
>
> shadow_start = kasan_mem_to_shadow((void *)region_start);
> shadow_end = kasan_mem_to_shadow((void *)region_end);
> --
> 2.29.2.222.g5d2a92d10f8-goog
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
or software tag-based mode.
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: If77d21f655d52ef3e58c4c37fd6621a07f505f18
> ---
> mm/kasa
On Tue, Nov 10, 2020 at 11:11 PM Andrey Konovalov wrote:
>
> Both KASAN_GENERIC and KASAN_SW_TAGS have common dependencies, move
> those to KASAN.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potap
gt; }
>
> +bool check_invalid_free(void *addr)
> +{
> + u8 tag = get_tag(addr);
> + u8 shadow_byte = READ_ONCE(*(u8
> *)kasan_mem_to_shadow(reset_tag(addr)));
> +
> + return (shadow_byte == KASAN_TAG_INVALID) ||
> + (tag != KASAN_TAG_KERNEL && tag != shadow_byte);
> +}
&
off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I084e3214f2b40dc0bef7c5a9fafdc6f5c42b06a2
> ---
> mm/kasan/kasan.h | 6 ++
> mm/kasan/report.c | 162 -
ftware KASAN modes are enabled.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I055e0651369b14d3e54cdaa8c48e6329b2e8952d
&g
modes are enabled.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I6109ea96c8df41ef6d75ad71bf22c1c8fa234a9
-6,7 +6,7 @@
> * Author: Andrey Konovalov
> */
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#define pr_fmt(fmt) "kasan: " fmt
>
> #include
> #include
> @@ -41,6 +41,8 @@ void kasan_init_tags(void)
>
> for_each_possible_cpu(cpu)
>
ned-off-by: Andrey Konovalov
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I99aa2f7115d38a34ed85b329dadab6c7d6952416
> ---
> arch/arm64/kernel/setup.c | 2 +-
> arch/arm64/mm/kasan_init.c | 2 +-
> include/linux/kasan.h | 4 ++--
&g
adow" to implementation-neutral "metadata".
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I03706fe34b38da7860c39aa0968e
adow" to implementation-neutral "metadata".
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I18397dddbed6bc6d365ddcaf063a83948e115
the high
> * canonical half of the address space) cause out-of-bounds shadow memory
> reads
Perhaps this comment also needs to be updated.
> --
> 2.29.2.222.g5d2a92d10f8-goog
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636
ADOW" to implementation-neutral "META".
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: Id2d836bf4
tic bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> diff --git a/mm/kasan/report_sw_tags.c b/mm/kasan/report_sw_tags.c
> index c87d5a343b4e..add2dfe6169c 100644
> --- a/mm/kasan/report_sw_tags.c
> +++ b/mm/kasan/report_sw_tags.c
> @@ -80,6 +80,11 @@ void *find_first_bad_addr(void *addr, size_t size)
> return p;
> }
>
> +void metadata_fetch_row(char *buffer, void *row)
> +{
> + memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
Ditto.
> +}
> +
> void print_tags(u8 addr_tag, const void *addr)
> {
> u8 *shadow = (u8 *)kasan_mem_to_shadow(addr);
> --
> 2.29.2.222.g5d2a92d10f8-goog
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
alov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: Icd29bd0c6b1d3d7a0ee3d50c20490f404d34fc97
> ---
> arch/arm64/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ar
On Tue, Nov 10, 2020 at 11:12 PM Andrey Konovalov wrote:
>
> This patch adds a configuration option for a new KASAN mode called
> hardware tag-based KASAN. This mode uses the memory tagging approach
> like the software tag-based mode, but relies on arm64 Memory Tagging
> Extension feature for tag
G_KASAN_HW_TAGS is enabled.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I51ebd3f9645e6330e5a92973bf7c86b62d632c2b
> ---
> arch/arm64/include/asm/cache.h | 3 +++
>
iewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I5d1117e6a991cbca00d2cfb4ba66e8ae2d8f513a
> ---
> mm/kasan/kasan.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index ae7def3b725b..d745a78745
ascino
> Reviewed-by: Marco Elver
> Acked-by: Vasily Gorbik
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I2a622db0cb86a8feb60c30d8cb09190075be2a90
> ---
> arch/s390/boot/string.c | 1 +
> arch/x86/boot/compressed/misc.h | 1 +
> 2 files changed, 2 in
On Wed, Nov 11, 2020 at 4:22 PM Alexander Potapenko wrote:
>
> On Tue, Nov 10, 2020 at 11:12 PM Andrey Konovalov
> wrote:
> >
> > This is a preparatory commit for the upcoming addition of a new hardware
> > tag-based (MTE-based) KASAN mode.
> >
> >
ned-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I91e661e2c1627783cb845d877c6371dfc8779505
> ---
> arch/arm64/Kconfig | 2 +-
> arch/arm64/Makefile
in EL1, so it's
> impossible to find out the size of the access the caused the fault.
> Adapt KASAN reporting code to handle this case.
>
> Signed-off-by: Andrey Konovalov
> Co-developed-by: Vincenzo Frascino
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marin
On Tue, Nov 10, 2020 at 11:12 PM Andrey Konovalov wrote:
>
> Hardware tag-based KASAN is now ready, enable the configuration option.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Acked-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
On Tue, Nov 10, 2020 at 11:12 PM Andrey Konovalov wrote:
>
> Add documentation for hardware tag-based KASAN mode and also add some
> clarifications for software tag-based mode.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
> ---
> Change-Id:
On Wed, Nov 11, 2020 at 7:50 PM Andrey Konovalov wrote:
>
> On Wed, Nov 11, 2020 at 4:04 PM Alexander Potapenko wrote:
> >
> > On Tue, Nov 10, 2020 at 11:11 PM Andrey Konovalov
> > wrote:
> > >
> > > Software tag-based KASAN mode is fully initi
On Wed, Nov 11, 2020 at 7:52 PM 'Andrey Konovalov' via kasan-dev
wrote:
>
> On Wed, Nov 11, 2020 at 4:09 PM Alexander Potapenko wrote:
> >
> > On Tue, Nov 10, 2020 at 11:11 PM Andrey Konovalov
> > wrote:
> > >
> > > This is a preparatory commit f
if(WIFEXITED(res))
> + results[i] = WEXITSTATUS(res);
> + else
> + --i;
Won't we get stuck in this loop if fork() returns -1 for one of the processes?
> + }
> +
> + for (int i = 0; i < NUM_ITERATIONS
: Vincenzo Frascino
> Acked-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I39f3c4d4f29299d4fbbda039bedf230db1c746fb
> ---
> mm/page_alloc.c | 4 +++-
> mm/page_poison.c | 2 +-
> mm/slub.c| 29 -
> 3 files changed, 20 ins
On Thu, Nov 12, 2020 at 5:09 PM Marco Elver wrote:
>
> On Thu, 12 Nov 2020 at 16:59, Alexander Potapenko wrote:
> >
> > On Tue, Nov 10, 2020 at 11:12 PM Andrey Konovalov
> > wrote:
> > >
> > > From: Vincenzo Frascino
> > >
> > >
mmon KASAN code to support the new mode.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Acked-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I8a8689ba098174a4d0ef3f1d008178387c80ee1c
> ---
> arch/arm64/include/asm/memory.h |
attributes are changed to a protected
> > +state, and cause page faults on any attempted access. Such page faults are
> > then
> > +intercepted by KFENCE, which handles the fault gracefully by reporting an
> > +out-of-bounds access.
>
> ... and marking the page as accessible
san_unpoison_range(), and introduce internal
> functions (un)poison_range() (without kasan_ prefix).
>
> Co-developed-by: Marco Elver
> Signed-off-by: Marco Elver
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Ale
it.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I0b627b24187d06c8b9bb2f1d04d94b3d06945e73
> ---
> mm/kasan/init.c | 10 --
> mm/kas
Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: Ib46cb444cfdee44054628940a82f5139e10d0258
> ---
> Documentation/dev-tools/kasan.rst | 80 +++
> 1 file changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/dev-tools/kasan.
to
> allow the usage of ALTERNATIVE()s with MTE instructions.
>
> Signed-off-by: Vincenzo Frascino
> Signed-off-by: Andrey Konovalov
> Reviewed-by: Catalin Marinas
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I172e15e4c189f073e4c14a10276b276092e76536
> ---
feature for tag management and access checking.
>
> Signed-off-by: Andrey Konovalov
> Co-developed-by: Vincenzo Frascino
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: I246c2def9fffa6563278db1bddfbe742ca7b
t the memset might result in a tag
> mismatch.
>
> Untag the address to avoid spurious faults.
>
> Cc: Andrew Morton
> Signed-off-by: Vincenzo Frascino
> Signed-off-by: Andrey Konovalov
Reviewed-by: Alexander Potapenko
> ---
> Change-Id: If12b4944383575b8bbd7d971
> actually enabled")
> and 4c4c75881536 ("arm64, kfence: enable KFENCE for ARM64") went in the
> same day via different trees.
>
> Signed-off-by: Anders Roxell
Reviewed-by: Alexander Potapenko
Thanks!
> ---
>
> I got this build error in todays next-20201204.
On Fri, Nov 6, 2020 at 10:21 AM Marco Elver wrote:
>
> Describe parameter @addr correctly by delimiting with ':'.
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Marco Elver
Reviewed-by: Alexander Potapenko
> ---
> include/linux/kfence.h | 2 +-
> 1 file ch
ng
the full graphical stack are a lot more interesting.
Those often have big variance though, and are very specific to the
particular system.
Alex
> https://git.kernel.org/linus/81a56f6dcd20
>
> --
> Kees Cook
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
On Tue, Jul 30, 2019 at 9:54 PM Linus Torvalds
wrote:
>
> On Tue, Jul 30, 2019 at 6:53 AM Alexander Potapenko wrote:
> >
> > I wonder how hard it should be to make a zero-filling GCC plugin?
> > I'm not a big fan of hacking GCC, but it shouldn't differ much from
>
therwise be optimized out, so combining
> + this with CONFIG_KASAN_STACK can lead to a stack overflow
> + and is disallowed.
> +
> config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> bool "zero-init anything passed by reference (very strong)&
On Mon, Jul 22, 2019 at 4:26 PM Arnd Bergmann wrote:
>
> On Mon, Jul 22, 2019 at 3:43 PM Alexander Potapenko wrote:
> > On Mon, Jul 22, 2019 at 1:41 PM Arnd Bergmann wrote:
> > >
> > > KASAN_STACK is currently implied by KASAN on gcc, but could be made a
> >
ontent.com/google/kasan/kfence/Documentation/dev-tools/kfence.rst
> >
> > [1] http://llvm.org/docs/GwpAsan.html
> > [2] https://linux.die.net/man/3/efence
> >
> > Alexander Potapenko (6):
> > mm: add Kernel Electric-Fence infrastructure
> > x86, kfence: ena
> Could you instead do:
>
> #if defined(CONFIG_KFENCE) && defined(CONFIG_HAVE_ARCH_KFENCE_STATIC_POOL)
> delete_object_part((unsigned long)__kfence_pool, KFENCE_POOL_SIZE);
> #endif
Thanks, we'll apply this to v2!
--
Alexander Potapenko
Software Engineer
Google
mem_ptr -= KASAN_SHADOW_SCALE_SIZE;
> + mem_ptr -= KASAN_GRANULE_SIZE;
> }
>
> while (shadow_ptr >= shadow_bottom && *shadow_ptr ==
> KASAN_STACK_LEFT) {
> shadow_ptr--;
> - mem_ptr -= KASAN_SHADOW_SCALE
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> new file mode 100644
> index ..4888084ecdfc
> --- /dev/null
> +++ b/mm/kasan/shadow.c
> @@ -0,0 +1,509 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This file contains KASAN shadow runtime code.
I think it will be nice to
On Tue, Sep 15, 2020 at 11:17 PM Andrey Konovalov wrote:
>
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Hardware tag-based KASAN will also be using tag-based approach, so rename
> tags.c to tags_sw.c and report_tags.c to
On Fri, Sep 18, 2020 at 11:41 AM Alexander Potapenko wrote:
>
> On Tue, Sep 15, 2020 at 11:17 PM Andrey Konovalov
> wrote:
> >
> > This is a preparatory commit for the upcoming addition of a new hardware
> > tag-based (MTE-based) KASAN mode.
> >
> > Hard
> Also, as we are going to have CONFIG_KASAN_{SW,HW}_TAGS, won't it be
> better to call the files {report_,}tags_{sw,hw}.c ?
Sorry for the typo, I meant "{report_,}{sw,hw}_tags.c, mirroring the
config names.
>
> Signed-off-by: Walter Wu
> Suggested-by: Marco Elver
> Acked-by: Marco Elver
> Reviewed-by: Dmitry Vyukov
> Reviewed-by: Andrey Konovalov
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> ---
>
> v2:
> - Thanks for Marco suggestion.
> - We modify aux
> ---
> Documentation/dev-tools/kasan.rst | 5 +++--
> kernel/time/timer.c | 3 +++
> kernel/workqueue.c| 3 +++
> lib/test_kasan_module.c | 55
> +++
> mm/kasan/report.c | 4 ++--
> 5 files
On Thu, Sep 24, 2020 at 1:55 PM Marco Elver wrote:
>
> On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko wrote:
> >
> > On Thu, Sep 24, 2020 at 6:05 AM Walter Wu wrote:
> > >
> > > The aux_stack[2] is reused to record the call_rcu() call stack,
> > &
From: Albert van der Linde
To test fault-tolerance of user memory acceses in x86, add support for
fault injection.
Make both put_user() and get_user() fail with -EFAULT, and clear_user()
fail by not clearing any bytes.
Reviewed-by: Akinobu Mita
Reviewed-by: Alexander Potapenko
Signed-off
more likely to happen than of 0xAA?).
>
> So my conclusion:
> - We can remove PAGE_POISONING_NO_SANITY because it only makes sense with
> PAGE_POISONING_ZERO, and we can use init_on_free instead
Agreed.
> - We can also probably remove PAGE_POISONING_ZERO, because if we want to do
>
Will,
> Given that the pool is relatively small (i.e. when compared with our virtual
> address space), dedicating an area of virtual space sounds like it makes
> the most sense here. How early do you need it to be available?
How do we assign struct pages to a fixed virtual space area (I'm
, but not former.
Agreeing with everything Marco said I can only add that it would be
nice to have a separate discussion about the existing memory debugging
subsystems and the need to remove any of them.
Having many tools in a toolbox does not hurt, but we need to ensure
that all the tools in questi
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
ituation...
>
> Folks, could you test the following?
>
> copy_xstate_to_kernel(): don't leave parts of destination uninitialized
>
> copy the corresponding pieces of init_fpstate into the gaps instead.
>
> Signed-off-by: Al Viro
Tested-by: Alexander Potapenko
> ---
&
lized value is returned when all the xattr on the file
> > are ovl_is_private_xattr(), which is actually a successful case,
> > therefore we initialize |error| with 0.
> >
> > Signed-off-by: Alexander Potapenko
> > Cc: Kees Cook
> > Cc: Roy Yang
> > Cc: # 4.1
>
> Ple
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sig
On Tue, Sep 26, 2017 at 5:02 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Tue, Sep 26, 2017 at 7:53 AM, Alexander Potapenko
> wrote:
>> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
>> skb->data[0] in the case the skb is empt
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Signed-
se IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
>
> And name this va
On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
>>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>>
>>&
his are mitigated by building with
>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>>>>
>>>> Reported-by: Alexander Potapenko
>>>> Cc: "David S. Miller"
>>>> Cc: net...@vger.kernel.org
>>>> Signed-off-by: Kees Cook
>>&
stackdepot used to call memcmp(), which compiler tools normally
instrument, therefore every lookup used to unnecessarily call
instrumented code.
This is somewhat ok in the case of KASAN, but under KMSAN a lot of time
was spent in the instrumentation.
Signed-off-by: Alexander Potapenko
---
lib
On Thu, Nov 16, 2017 at 4:08 PM, Andrey Ryabinin
wrote:
>
>
> On 11/15/2017 08:34 PM, Alexander Potapenko wrote:
>> stackdepot used to call memcmp(), which compiler tools normally
>> instrument, therefore every lookup used to unnecessarily call
>> instrumented c
__kasan_unpoison_stack() and __asan_allocas_unpoison()).
So maybe this BUILD_BUG_ON can be added in a separate patch as it's
not specific to what Marco is doing here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "kasan-dev" group.
&
kmalloc() shouldn't sleep while in RCU critical section, therefore
use GFP_ATOMIC instead of GFP_KERNEL.
The bug has been spotted by the 0day kernel testing robot.
Fixes: 7e659650cbda ("lib: introduce test_meminit module")
Signed-off-by: Alexander Potapenko
Cc: Kees Cook
Cc: Andrew
1447,10 @@ static inline bool slab_free_freelist_hook(struct
> kmem_cache *s,
> : 0;
> memset((char *)object + s->inuse, 0,
>s->size - s->inuse - rsize);
> - set_freepointer(s, object, next);
> + set_freepointer(s, object, p);
> + p = object;
> } while (object != old_tail);
> + }
>
> /*
>* Compiler cannot detect this function can be removed if slab_free_hook()
>
This one looks good, care to send a patch? Otherwise I can do that for you.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
gt; > > or another value in the chain.
> > >
> > > Reported-by: kernel test robot
> > > Signed-off-by: Laura Abbott
> >
> > Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
> > init_on_free=1 boot options")
>
> Reviewed-by:
size", not object_size.)
> >
>
> I suppose Alexander is going to revise the series anyway, so he can probably
> take care of the issue here in the new version as well. Something like this,
>
> memset(object, 0, s->object_size);
> memset(object, 0, s->size - s->
Hi Haozhong, Paolo,
KMSAN bot is hitting this warning every now and then.
Is it possible to replace it with a pr_warn()?
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und
spotmail.com
> Suggested-by: Alexander Potapenko
> Signed-off-by: Paolo Bonzini
Acked-by: Alexander Potapenko
> ---
> arch/x86/kvm/x86.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 83aefd7598
;);
> return -ENOMEM;
> }
> - gspca_dev->usb_buf = kmalloc(USB_BUF_SZ, GFP_KERNEL);
> + gspca_dev->usb_buf = kmalloc(USB_BUF_SZ, GFP_KERNEL|__GFP_ZERO);
How about calling kzalloc() then?
> if (!gspca_dev->usb_buf) {
> pr_err("out of memory\n");
> ret = -ENOMEM;
> --
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20190608054928.4792-1-hdanton%40sina.com.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
_media(struct us_data *us)
> static int alauda_check_media(struct us_data *us)
> {
> struct alauda_info *info = (struct alauda_info *) us->extra;
> - unsigned char status[2];
> + unsigned char *status = us->iobuf;
> int rc;
>
> rc
c:843
> pppoe_sendmsg+0xa6/0xb90 drivers/net/ppp/pppoe.c:843
> =
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers
e]
> iov_iter_get_pages_alloc+0x18a9/0x21c0 lib/iov_iter.c:1403
> default_file_splice_read fs/splice.c:385 [inline]
> do_splice_to+0x4fc/0x14f0 fs/splice.c:871
> splice_direct_to_actor+0x45c/0xf50 fs/splice.c:950
> do_splice_direct+0x342/0x580 fs/splice.c:1059
> do_sendfile+0x101
_poison_pages(page, 1 << order, 0);
> > if (want_init_on_free())
> > kernel_init_free_pages(page, 1 << order);
> > +
> > + kernel_poison_pages(page, 1 << order, 0);
> > if (debug_pagealloc_enabled())
> > kernel_m
On Fri, Jun 21, 2019 at 2:26 PM Qian Cai wrote:
>
> On Fri, 2019-06-21 at 12:39 +0200, Alexander Potapenko wrote:
> > On Fri, Jun 21, 2019 at 3:01 AM Kees Cook wrote:
> > >
> > > On Thu, Jun 20, 2019 at 04:46:06PM -0400, Qian Cai wrote:
> > > > The
On Fri, Jun 21, 2019 at 4:56 PM Qian Cai wrote:
>
> On Fri, 2019-06-21 at 16:37 +0200, Alexander Potapenko wrote:
> > On Fri, Jun 21, 2019 at 2:26 PM Qian Cai wrote:
> > >
> > > On Fri, 2019-06-21 at 12:39 +0200, Alexander Potapenko wrote:
> > > > On Fri
501 - 600 of 1024 matches
Mail list logo
