Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Nov 2015 10:12:43 -0800
From: Kees Cook <keescook@...gle.com>
To: Jeff Law <law@...hat.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 Wed, Nov 18, 2015 at 3:07 PM, Jeff Law <law@...hat.com> wrote:
> Kees asked me to bring this discussion over to the list...  So here we go...
>
> On 11/13/2015 03:27 PM, Kees Cook wrote:
>>>
>>>
>>> The discussion had a reference to a GCC issue without any real details
>>> (intentional overflow).  From what I read, I suspect the culprit is the
>>> early folding that's done by the front-ends.
>>
>>
>> Yeah, that's one of the things that got mentioned.
>>
>>> We're currently in the process of trying to defer folding until the
>>> transition from front-end tree/generic to gimple.  We're starting with
>>> C++
>>> because delayed folding is essentially a requirement for proper
>>> implementation of certain language features.  C support ought to be
>>> relatively easy once we've got the C++ front-end bits in place.
>>
>>
>> I would be forever grateful if you could join the list and comment on
>> this progress. I think a lot of people would be very glad to see some
>> mention of the plans here.
>
> It's certainly recognized that the folding done by the front-ends has
> significant disadvantages for a variety of use cases.
>
> The most important one for this discussion is it's impossible for code
> outside the front-end to see expressions in a form that is reasonably close,
> if not the same as what appeared in the input source.
>
> So the natural solution is to delay folding of expressions until a later
> point in the compilation pipeline.  Ideally until we hit the generic/gimple
> barrier.  We also want to delay canonicalization, reassociation and other
> transformations that hide the original structure of expressions.
>
> The initial focus of that work is for the C++ front-end (where it's needed
> to implement certain language features correctly).  I haven't checked if the
> original form survives until a point where a plugin could examine the
> original form.  The work isn't terribly deep or complex, but tedious as most
> diagnostics require folded expressions.  Delayed folding isn't a strict
> language requirement for C, so we haven't invested any effort yet into
> replicating the work in the C front-end.
>
> It's also still the case that things like operand shortening and some
> canonicalizations still occur -- they're in a different part of the
> compiler.  There's a plan and a fair amount of code to defer those
> operations, but it didn't land in time for the upcoming GCC 6 release.

Thanks for the details!

>>
>>> The best way forward will be to get a bug report filed.  That allows
>>> tracking the issue, helps with resource juggling and ultimately reaches a
>>> wider audience.
>>
>>
>> If you can, I'd love to see what you think about the existing open
>> bugs (at the corrected URL above). I'm much less familiar with these
>> internals, so talking on the list or in the bugs would be fantastic --
>> or aiming me at someone else I should pester. :)
>>
>> Thanks for the reply! I think at the very least, we can provide you
>> with some immediate feedback on some of these features. :)
>
> 41757 is already fixed.  It is highly unlikely that it would be backported
> to 4.5/4.6 era compilers -- we've stopped working on those vintage
> compilers.  I've closed this report.
>
> 46354 I don't really have any state here.  I try pretty hard never to look
> at the structure/type layout code.  It's amazingly complex and easy to get
> wrong.  The BZ text implies that the kernel is relying on this behaviour, so
> one possible outcome is current behaviour gets documented and set it in
> stone.  Unfortunately the guy I'd like to pass this off to just disappeared
> on extended PTO :(
>
> 61311 anything in the streaming space is primarily handled by the SuSE guys.
> However, in terms of header files, my recollection is that there's supposed
> to be an aggregator for plugins so that they're isolated from the header
> file restructuring that's going on.  I haven't actually tried it though.
>
> 61313 this was supposed to fix some problem with plugins on cross targets.
> Apparently something went wrong.  It looks like there's a bad interaction
> with collect2.  I've alerted the original author of the offending change.

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

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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.