All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Potapenko <glider@google.com>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH] x86: suppress KMSAN reports in arch_within_stack_frames()
Date: Tue, 22 Nov 2022 09:17:18 +0100	[thread overview]
Message-ID: <Y3yFjm98nqQEsnVN@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAG_fn=WMivfVzE35=LH5y1OeO=_FvnfRkybvE15EaOL2yH0y0g@mail.gmail.com>

On Mon, Nov 21, 2022 at 03:27:49PM +0100, Alexander Potapenko wrote:

> In other words, for normal instrumentation:
>  - locals are explicitly marked as uninitialized;
>  - shadow values are calculated for arithmetic operations based on their inputs;
>  - shadow values are checked for branches, pointer dereferences, and
> before passing them as function arguments;
>  - memory stores update shadow for affected variables.
> 
> For __no_kmsan_checks:
>  - locals are explicitly marked as initialized;
>  - no instrumentation is added for arithmetic operations, branches,
> pointer dereferences;
>  - all function arguments are marked as initialized;
>  - stores always mark memory as initialized.
> 
> For __no_sanitize_memory:
>  - no instrumentation for locals (they may end up being initialized or
> uninitialized - doesn't matter, because their shadow values are never
> used);
>  - no instrumentation for arithmetic operations, branches, pointer dereferences;
>  - no instrumentation for function calls (an instrumented function
> will receive garbage shadow values from a non-instrumented one);
>  - no instrumentation for stores (initialization done in these
> functions is invisible).

Thanks! That is a great summary.

  reply	other threads:[~2022-11-22  8:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 17:23 [PATCH] x86: suppress KMSAN reports in arch_within_stack_frames() Alexander Potapenko
2022-11-21 10:22 ` Peter Zijlstra
2022-11-21 10:28   ` Alexander Potapenko
2022-11-21 11:38     ` Peter Zijlstra
2022-11-21 14:27       ` Alexander Potapenko
2022-11-22  8:17         ` Peter Zijlstra [this message]
2022-11-30  5:40 ` Eric Biggers
2023-01-12  5:40   ` Eric Biggers
2023-01-27 16:12     ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3yFjm98nqQEsnVN@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiggers@kernel.org \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.