Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.