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.