[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <564F55E9.2030007@redhat.com>
Date: Fri, 20 Nov 2015 10:18:33 -0700
From: Jeff Law <law@...hat.com>
To: Kees Cook <keescook@...gle.com>
Cc: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
Richard Henderson <rth@...hat.com>, PaX Team <pageexec@...email.hu>
Subject: Re: GCC upstream contacts for Linux kernel bugs
On 11/19/2015 11:12 AM, Kees Cook wrote:
> I remember one more that breaks the kernel's ability to do
> compile-time evaluation of target sizes, which is a useful
> vulnerability mitigation. CONFIG_DEBUG_STRICT_USER_COPY_CHECKS isn't
> useful any more since it was forced to be disabled in
> https://git.kernel.org/linus/2fb0815c9ee6
>
> original: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48880
> duped to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639
Yea, I'm already familiar with these. 46639 gets evaluated each release
cycle as its a regression.
Essentially function splitting is setting up a situation where things
necessary to determine a compile-time constant are in two different places.
The specific case in 46639 should be solved with the ability to run a
minimal jump threading pass early in the optimizer pipeline. To do
that we need to detangle jump threading from vrp & the dominator optimizer.
The main infrastructure for that work landed a couple weeks ago. It's
not clear yet if the remainder of the work will slip in during the
bugfixing phase or have to wait for gcc7. It will largely depend on how
much additional work needs to occur. I don't think it's too bad, but
I've mostly been focused on getting the infrastructure bits in place,
rather than exploiting them at this phase.
jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
