moving 'struct page_frag_cache' to mm_types_task.h as
> suggested by Alexander, see [3].
>
> 1. https://lore.kernel.org/all/20230411160902.4134381-3-dhowe...@redhat.com/
> 2. https://lore.kernel.org/all/15623dac-9358-4597-b3ee-3694a5956...@gmail.com/
> 3.
> https://lore.
e fragment from the
> ptr_ring and free the fragment.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
> ---
> tools/testing/selftests/mm/Makefile | 3 +
> tools/testing/selftests/mm/page_frag/Makefile | 18 ++
> .../selftests/mm/page_frag/page_frag_te
stian Brauner
Cc: Seth Forshee
Cc: Miklos Szeredi
Cc: Vivek Goyal
Cc: German Maglione
Cc: Amir Goldstein
Cc: Bernd Schubert
Cc:
Signed-off-by: Alexander Mikhalitsyn
Reviewed-by: Christian Brauner
---
v3:
- this commit added
---
fs/fuse/virtio_fs.c | 1 +
1 file changed, 1 inse
stian Brauner
Cc: Seth Forshee
Cc: Miklos Szeredi
Cc: Vivek Goyal
Cc: German Maglione
Cc: Amir Goldstein
Cc: Bernd Schubert
Cc:
Signed-off-by: Alexander Mikhalitsyn
---
v3:
- this commit added
---
fs/fuse/virtio_fs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs
On Sun, Aug 4, 2024 at 10:00 AM Yunsheng Lin wrote:
>
> On 8/3/2024 1:00 AM, Alexander Duyck wrote:
>
> >>
> >>>
> >>> As far as your API extension and naming maybe you should look like
> >>> something like bio_vec and borrow the naming
On Fri, Aug 2, 2024 at 3:05 AM Yunsheng Lin wrote:
>
> On 2024/8/1 23:21, Alexander Duyck wrote:
> > On Thu, Aug 1, 2024 at 6:01 AM Yunsheng Lin wrote:
> >>
> >> On 2024/8/1 2:13, Alexander Duyck wrote:
> >>> On Wed, Jul 31, 2024 at 5:50 AM Yunsheng Lin
On Thu, Aug 1, 2024 at 6:01 AM Yunsheng Lin wrote:
>
> On 2024/8/1 2:13, Alexander Duyck wrote:
> > On Wed, Jul 31, 2024 at 5:50 AM Yunsheng Lin wrote:
> >>
> >> Currently the page_frag API is returning 'virtual address'
> >> or 'va' wh
ng API mirroring the page_pool_alloc_va()
> API of the page_pool. So that callers expecting to deal with
> va, page or both va and page may call page_frag_alloc_va*,
> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
&
On Fri, 2024-07-19 at 17:33 +0800, Yunsheng Lin wrote:
> Use appropriate frag_page API instead of caller accessing
> 'page_frag_cache' directly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
> ---
> drivers/vhost/net.c | 2 +-
> in
ng API mirroring the page_pool_alloc_va()
> API of the page_pool. So that callers expecting to deal with
> va, page or both va and page may call page_frag_alloc_va*,
> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
eoshkevich
Reviewed-by: Alexander Potapenko
On Fri, Jun 21, 2024 at 2:27 AM Ilya Leoshkevich wrote:
>
> Add KMSAN vmalloc metadata areas to kernel_page_tables.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
uninitialized memory and UAF.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Thu, Jun 20, 2024 at 4:18 PM Alexander Potapenko wrote:
>
> On Thu, Jun 20, 2024 at 3:38 PM Ilya Leoshkevich wrote:
> >
> > On Thu, 2024-06-20 at 11:25 +0200, Alexander Gordeev wrote:
> > > On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich
On Thu, Jun 20, 2024 at 3:38 PM Ilya Leoshkevich wrote:
>
> On Thu, 2024-06-20 at 11:25 +0200, Alexander Gordeev wrote:
> > On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
> >
> > Hi Ilya,
> >
> > > +static inline bool is_lowcore_addr(voi
: Ilya Leoshkevich
> ---
> arch/s390/include/asm/kmsan.h | 59 +++
> 1 file changed, 59 insertions(+)
> create mode 100644 arch/s390/include/asm/kmsan.h
Acked-by: Alexander Gordeev
On Thu, Jun 20, 2024 at 1:19 PM Ilya Leoshkevich wrote:
>
> On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote:
> > On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich
> > wrote:
> > >
> > > put_user() uses inline assembly with precise constraints,
On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
Hi Ilya,
> +static inline bool is_lowcore_addr(void *addr)
> +{
> + return addr >= (void *)&S390_lowcore &&
> +addr < (void *)(&S390_lowcore + 1);
> +}
> +
> +static inline void *arch_kmsan_get_meta_or_null(void *ad
ess_enable() is to touch poisoned
> metadata without triggering KMSAN, is to unpoison its return value.
> However, this approach is too fragile. So simply disable the KMSAN
> checks in the respective functions.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
size);
> break;
> case 4:
> - rc = __get_user_asm((unsigned int *)x,
> + rc = __get_user_int((unsigned int *)x,
> (unsigned int __user *)ptr,
> size)
gt; it directly.
>
> Suggested-by: Alexander Potapenko
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich wrote:
>
> Add a wrapper for memset() that prevents unpoisoning. This is useful
> for filling memory allocator redzones.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> ---
> include/linux/kmsan.h |
On Thu, Jun 13, 2024 at 5:40 PM Ilya Leoshkevich wrote:
>
> Now that everything else is in place, enable KMSAN in Kconfig.
>
> Acked-by: Heiko Carstens
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
s stored in the lowcore_ptr[] array.
>
> When lowcore is accessed through virtual address 0, one needs to
> resolve metadata for lowcore_ptr[raw_smp_processor_id()].
>
> Expose kmsan_get_metadata() to make it possible to do this from the
> arch code.
>
> Signed-off-by: I
eft_pad);
> > | ^~~~
> > | memset
> > cc1: some warnings being treated as errors
> >
> > I haven't looked in deep, but reporting first. Do you have any idea?
> >
> > [1]
> >
On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich wrote:
>
> Even though the KMSAN warnings generated by memchr_inv() are suppressed
> by metadata_access_enable(), its return value may still be poisoned.
>
> The reason is that the last iteration of memchr_inv() returns
> `*start != value ? start :
ble memory, in turn
> causing virt_to_page_or_null() in kmsan_init_alloc_meta_for_range() to
> return NULL, which leads to kernel panic shortly after.
>
> Since the padding bytes are not used, drop the rounding.
Nice catch, thanks!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
isable() functions to KMSAN.
>
> Acked-by: Vlastimil Babka
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
n, where possible.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On 18.06.24 12:21, Ard Biesheuvel wrote:
On Mon, 17 Jun 2024 at 23:01, Alexander Graf wrote:
On 17.06.24 22:40, Steven Rostedt wrote:
On Mon, 17 Jun 2024 09:07:29 +0200
Alexander Graf wrote:
Hey Steve,
I believe we're talking about 2 different things :). Let me rephrase a
bit and m
On Tue, Jun 18, 2024 at 11:40 AM Ilya Leoshkevich wrote:
>
> On Tue, 2024-06-18 at 11:24 +0200, Alexander Potapenko wrote:
> > On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich
> > wrote:
> > >
> > > put_user() uses inline assembly with precise constraints,
inter. While at it, prettify them too.
>
> Suggested-by: Heiko Carstens
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Thu, Jun 13, 2024 at 5:39 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 d
[resend because Thunderbird decided to send the previous version as HTML :(]
On 17.06.24 22:40, Steven Rostedt wrote:
On Mon, 17 Jun 2024 09:07:29 +0200
Alexander Graf wrote:
Hey Steve,
I believe we're talking about 2 different things :). Let me rephrase a
bit and make a concrete ex
Hey Steve,
On 13.06.24 19:12, Steven Rostedt wrote:
On Thu, 13 Jun 2024 18:54:12 +0200
Alexander Graf wrote:
Do you have a "real" pstore on these systems that you could store
non-volatile variables in, such as persistent UEFI variables? If so, you
could create an actually persiste
Hey Steve,
On 13.06.24 17:55, Steven Rostedt wrote:
Reserve unspecified location of physical memory from kernel command line
Background:
In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract
dmesg output and some other information when a crash happens in the field.
(This
d8c06f6ae199e1133ae8/osl/namespace_linux.go#L682
[3]
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 19 +++
1 file changed, 15 insertions(+),
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Suggested-by: Julian Anastasov
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a
d8c06f6ae199e1133ae8/osl/namespace_linux.go#L682
[3]
Cc: Stéphane Graber
Cc: Christian Brauner
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 21 +
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Suggested-by: Julian Anastasov
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a
6f6ae199e1133ae8/osl/namespace_linux.go#L682
Cc: Stéphane Graber
Cc: Christian Brauner
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 21 +++--
1 file ch
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Suggested-by: Julian Anastasov
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net
On Mon, 2024-04-15 at 21:19 +0800, Yunsheng Lin wrote:
> Currently most of the API for page_frag API is returning
> 'virtual address' as output or expecting 'virtual address'
> as input, in order to differentiate the API handling between
> 'virtual address' and 'struct page', add '_va' suffix to th
sov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilt
/disk-fbafc3e6.raw.xz
> > > vmlinux:
> > > https://storage.googleapis.com/syzbot-assets/8b490af009d5/vmlinux-fbafc3e6.xz
> > > kernel image:
> > > https://storage.googleapis.com/syzbot-assets/202ca200f4a4/bzImage-fbafc3e6.xz
> > >
> > > IMPORTANT: if
On Mon, Jan 8, 2024 at 12:25 AM Yunsheng Lin wrote:
>
> On 2024/1/5 23:35, Alexander H Duyck wrote:
> > On Wed, 2024-01-03 at 17:56 +0800, Yunsheng Lin wrote:
> >> Currently there seems to be three page frag implementions
> >> which all try to allocate order 3 pag
On Mon, Jan 8, 2024 at 1:06 AM Yunsheng Lin wrote:
>
> On 2024/1/6 0:06, Alexander H Duyck wrote:
> >>
> >> static void handle_tx_copy(struct vhost_net *net, struct socket *sock)
> >> @@ -1353,8 +1318,7 @@ static int vhost_net_open(struct i
On Wed, 2024-01-03 at 17:56 +0800, Yunsheng Lin wrote:
> The page frag in vhost_net_page_frag_refill() uses the
> 'struct page_frag' from skb_page_frag_refill(), but it's
> implementation is similar to page_frag_alloc_align() now.
>
> This patch removes vhost_net_page_frag_refill() by using
> 'str
On Wed, 2024-01-03 at 17:56 +0800, Yunsheng Lin wrote:
> When draining a page_frag_cache, most user are doing
> the similar steps, so introduce an API to avoid code
> duplication.
>
> Signed-off-by: Yunsheng Lin
> Acked-by: Jason Wang
Looks good to me.
Reviewed-by: Alexander Duyck
masking off
> __GFP_DIRECT_RECLAIM for order 3 page allocation to avoid
> possible pressure for mm.
>
> Signed-off-by: Yunsheng Lin
> CC: Alexander Duyck
> ---
> drivers/vhost/net.c | 2 +-
> mm/page_alloc.c | 4 ++--
> net/core/sock.c | 2 +-
> 3 files c
On Tue, Jan 02, 2024 at 04:05:31PM +0100, Heiko Carstens wrote:
Hi Heiko,
...
> > @@ -253,9 +253,17 @@ static unsigned long setup_kernel_memory_layout(void)
> > MODULES_END = round_down(__abs_lowcore, _SEGMENT_SIZE);
> > MODULES_VADDR = MODULES_END - MODULES_LEN;
> > VMALLOC_END = MODUL
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
>
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
it more careful than x86: allocate exactly MODULES_LEN
> for the module shadow and origins, and then take 2/3 of vmalloc for
> the vmalloc shadow and origins. This ensures that users passing small
> vmalloc= values on the command line do not cause module metadata
> collisions.
>
>
n fine.
Cc: sta...@vger.kernel.org
Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module")
Reported-by: Alexander Graf
Signed-off-by: Steven Rostedt (Google)
Thanks a bunch for the super quick turnaround time for the fix! I can
confirm that I'm no longer seeing the warning
shkevich
Reviewed-by: Alexander Potapenko
the whole dest manually with kmsan_unpoison_memory().
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
Hi,
On Thu, Dec 14, 2023 at 10:01 PM Alexander Aring wrote:
>
> Hi,
>
> On Mon, Dec 4, 2023 at 3:57 AM Miquel Raynal
> wrote:
> >
> > Hi Zhang,
> >
> > zhang_shur...@foxmail.com wrote on Sat, 2 Dec 2023 22:58:52 +0800:
> >
> > > The syz
()
> > which indicates hdr.fc.security_enabled should be 0. However, it is set to
> > be cb->secen before.
> > Later, ieee802154_hdr_push_sechdr is invoked, causing KMSAN complains
> > uninit-value issue.
>
> I am not too deeply involved in the security hea
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 t
64() definitions, 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
lloc_low().
> But since 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 -numme
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 *)&S390_lowcore &&
> + addr < (void *)(&S390_lowcore + 1)) {
> + /*
> +* Different lowcores accessed via S390_lowcore are described
> +
> 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 s390?
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. bui
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 precis
ngs 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
arnings 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: Ily
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 g
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).
Y
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Add a KMSAN check to the CKSM inline assembly, similar to how it was
> done for ASAN in commit e42ac7789df6 ("s390/checksum: always use cksm
> instruction").
>
> Acked-by: Alexander Gordeev
> Signed-off
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 asse
ds.
>
> 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 Thu, Nov 16, 2023 at 04:03:13PM +0100, Alexander Potapenko wrote:
Hi Alexander!
> > /* allow vmalloc area to occupy up to about 1/2 of the rest virtual
> > space left */
> > vmalloc_size = min(vmalloc_size, round_down(VMALLOC_END / 2,
> > _REG
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 x86
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 | 2
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
nfig 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
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Comparing pointers with TASK_SIZE does not make sense when kernel and
> userspace overlap. Assume that we are handling user memory access in
> this case.
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leo
ts.
Good catch, thank you!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Adjust the stack size for the KMSAN-enabled kernel like it was done
> for the KASAN-enabled one in commit 7fef92ccadd7 ("s390/kasan: double
> the stack size"). Both tools have similar requirements.
>
> Re
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.
KMSAN for now.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
sting.
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 backchains. Therefor
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
> ---
> arch/s390/ke
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
metadata"
1 - 100 of 3435 matches
Mail list logo
