[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLWnfR_a_VR_bq+vpA5NXCLafuFP-9AEVGGjr7pBpZ4XA@mail.gmail.com>
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.
