I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files.
https://bugs.openjdk.java.net/browse/JDK-8032045 http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ This version is, hopefully, almost ready to be pushed. Mike On Feb 20 2014, at 15:43 , Mike Duigou <mike.dui...@oracle.com> wrote: > Hello all; > > This issue is a followon to JDK-8030350 > (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the > compiler warnings used for compiling native code. The proposed changes > principally impact the Linux platform. > > While 8030350 was focused on compiler warnings which did not impact code > generation, this changeset will, for some configurations, change the native > code generated and likely change performance. These proposed option changes > prevent specific types of relocation table, stack and heap memory corruption > in native code. Preventing these types of memory corruption may be useful for > finding certain kinds of bugs though and do provide some minimal additional > protections against malicious attacks. They aren't, by any means, a > substitute for following appropriate secure coding guidelines. > > The rationale behind the implementation is as follows. For release builds > during the initial phase of JDK 9 I would like to enable only compile time > checks. This ends up being similar to the warnings in JDK-8030350. These > options have no runtime impact on footprint or performance and very minimal > additional compile time cost while providing value. **Release builds are not > expected to see any performance or footprint change as a result of this > changeset** > > For fast debug builds we can enable linker protections (relro) and static > compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be > moved to the production builds as well because it has no runtime cost or > executable size cost. > > For slow debug builds we can enable full linker protection (at a potential > cost in startup time), runtime bounds checks and stack protection > (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable > -fprotect-stack-strong when available in GCC 4.9 > > The basis for enabling the additional protections in debug builds is that it > will help us find bugs in our native code and we aren't as concerned in debug > builds with footprint and performance. Since many developers already do their > personal builds in fastdebug or slowdebug mode for testing this will provide > good opportunity to shake out any problems with the options while not > impacting release builds. Should we find that any of the options provide > significant value for their cost we can move them to fastdebug or release. If > any of the options prove too costly they can be demoted or removed entirely. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ > > Additional to enabling the various compiler options I attempted to > rationalize some of the skew between the various > hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing > existing behaviour. I have also introduced the new -Og "optimize for > debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG > definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} > optimization options. > > Thanks, > > Mike
