From: Kees Cook <keescook@chromium.org>
To: Alexander Potapenko <glider@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, kasan-dev@googlegroups.com,
linux-mm@kvack.org
Subject: Re: -Wmacro-redefined in include/linux/fortify-string.h
Date: Wed, 19 Oct 2022 10:30:54 -0700 [thread overview]
Message-ID: <202210191030.EC5C138E@keescook> (raw)
In-Reply-To: <CAG_fn=WYnfNHC3S1S=mCTKTnzL=UuH7Oz4W3HjsTXEQUtjrxtw@mail.gmail.com>
On Wed, Oct 19, 2022 at 09:48:27AM -0700, Alexander Potapenko wrote:
> On Wed, Oct 19, 2022 at 8:37 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi all,
> >
> > I am seeing the following set of warnings when building an x86_64
> > configuration that has CONFIG_FORTIFY_SOURCE=y and CONFIG_KMSAN=y:
>
> I was also looking into this issue recently, because people start
> running into it: https://github.com/google/kmsan/issues/89
>
> I have a solution that redefines __underlying_memXXX to __msan_memXXX
> under __SANITIZE_MEMORY__ in fortify-string.h and skips `#define
> memXXX __msan_memXXX` in string_64.h, making KMSAN kinda work with
> FORTIFY_SOURCE.
Oh good!
> Dunno if that's necessary though: KMSAN is a debugging tool anyway,
> and supporting it in fortify-string.h sounds excessive.
I'd much prefer letting them still work together.
--
Kees Cook
next prev parent reply other threads:[~2022-10-19 17:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 15:37 -Wmacro-redefined in include/linux/fortify-string.h Nathan Chancellor
2022-10-19 16:48 ` Alexander Potapenko
2022-10-19 17:30 ` Kees Cook [this message]
2022-10-19 17:29 ` Kees Cook
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=202210191030.EC5C138E@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@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.