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 <>
To: Jeff Law <>
Cc: "" <>, Richard Henderson <>, 
	PaX Team <>
Subject: Re: GCC upstream contacts for Linux kernel bugs

On Wed, Nov 18, 2015 at 3:07 PM, Jeff Law <> 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

duped to:



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.