From: Kees Cook <keescook@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH v4] fortify: Work around Clang inlining bugs
Date: Mon, 31 Jan 2022 13:13:30 -0800 [thread overview]
Message-ID: <202201311309.AFF4A0C@keescook> (raw)
In-Reply-To: <CAKwvOdmrzO9U9Cu5zB07t1C+Xh-kAzk_F-MisAxsrArhJVhSNw@mail.gmail.com>
On Mon, Jan 31, 2022 at 11:04:36AM -0800, Nick Desaulniers wrote:
> On Sun, Jan 30, 2022 at 10:22 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > To enable FORTIFY_SOURCE support for Clang, the kernel must work around
> > a pair of bugs, related to Clang's inlining:
> >
> > 1) Change all the fortified string APIs into macros with different
> > inline names to bypass Clang's broken inline-of-a-builtin detection:
> > https://bugs.llvm.org/show_bug.cgi?id=50322
> >
> > 2) Lift all misbehaving __builtin_object_size() calls into the macros
> > to bypass Clang's broken __builtin_object_size() arguments-of-an-inline
> > visibility:
> > https://github.com/ClangBuiltLinux/linux/issues/1401
>
> ^ mentions a difference in compilers for mode 1. I wonder if this
> patch could "hoist" the BOS calls into the macro ONLY for mode 1 and
> not mode 0 usage? i.e. the str* functions, not the mem* functions.
Everything (with a couple exceptions) is using mode 1 after the earlier
patches in the series. e.g.:
+#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
+ __builtin_object_size(p, 0), __builtin_object_size(q, 0), \
+ __builtin_object_size(p, 1), __builtin_object_size(q, 1), \
+ memcpy)
> It's too late to fix these in clang-13. If we get a fix in clang-14
> or later, what does that look like for this header? Is there a way we
If the bos mode 1 got fixed for Clang 14, this patch would likely be
dropped and the Clang + FORTIFY version check would be moved to Clang
14.
> can provide a different header than include/linux/fortify-string.h
> just for clang-13 (or whatever versions until the above are fixed)?
So much of it would be identical. This macro-ification is least
invasive, and it's pretty invasive.
> I don't see this series getting backported to stable, where older
> versions of clang may still be in use.
Right.
> I'm tempted to say "let's get get these 2 fixed in clang-14" but we'll
> probably have to trade something off the existing TODO list.
Agreed.
--
Kees Cook
prev parent reply other threads:[~2022-01-31 21:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-30 18:22 [PATCH v4] fortify: Work around Clang inlining bugs Kees Cook
2022-01-31 19:04 ` Nick Desaulniers
2022-01-31 21:13 ` Kees Cook [this message]
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=202201311309.AFF4A0C@keescook \
--to=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
/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.