On Tue, May 05, 2020 at 04:36:49PM -0700, Nick Desaulniers wrote:
> On Tue, May 5, 2020 at 4:22 PM Jason A. Donenfeld wrote:
> >
> > On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
> > >
> > > (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working
> > > _at all_ under Clang, so I
On Tue, May 5, 2020 at 5:22 PM Jason A. Donenfeld wrote:
>
> On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
> >
> > On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > > wrote:
> > > > I believe these issues are one in t
On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
>
> On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > wrote:
> > > I believe these issues are one in the same. I did a reverse bisect with
> > > Arnd's test case and converge
On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> wrote:
> > I believe these issues are one in the same. I did a reverse bisect with
> > Arnd's test case and converged on George's first patch:
> >
> > https://github.com/llvm/ll
This code generated by Clang here is the unfortunate side-effect of a
bug introduced during Clang-10's development phase. From discussion
with Kees on the links Nick mentioned, I surmise that FORTIFY in the
kernel never worked as well for Clang as it does for GCC today. In
many cases, it'd compile
On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
wrote:
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in l
On Tue, May 05, 2020 at 03:02:16PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Tue, May 5, 2020 at 2:55 PM Jason A. Donenfeld wrote:
> >
> > clang-10 has a broken optimization stage that doesn't enable the
> > compiler to prove at compile time that certain memcpys are within
> > b
clang-10 has a broken optimization stage that doesn't enable the
compiler to prove at compile time that certain memcpys are within
bounds, and thus the outline memcpy is always called, resulting in
horrific performance, and in some cases, excessive stack frame growth.
Here's a simple reproducer:
