From: Thomas Garnier Subject: Re: x86: PIE support and option to extend KASLR randomization Date: Thu, 24 Aug 2017 14:13:38 -0700 Message-ID: References: <20170810172615.51965-1-thgarnie@google.com> <20170811124127.kkb5pnkljz4umxuj@gmail.com> <20170815075609.mmzbfwritjzvrpsn@gmail.com> <20170816151235.oamkdva6cwpc4cex@gmail.com> <20170817080920.5ljlkktngw2cisfg@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Herbert Xu , "David S . Miller" , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Josh Poimboeuf , Arnd Bergmann , Matthias Kaehlcke , Boris Ostrovsky , Juergen Gross , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Joerg Roedel , Tom Lendacky , Andy Lutomirski , Borislav Petkov , Brian Gerst , "Kirill A . Shutemov" , "Rafael J . Wysocki" , Len Brown , Pavel Machek , Tejun Heo , Christoph La To: Ingo Molnar Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: List-Id: linux-crypto.vger.kernel.org On Thu, Aug 17, 2017 at 7:10 AM, Thomas Garnier wrote: > > On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar wrote: > > > > > > * Thomas Garnier wrote: > > > > > > > -model=small/medium assume you are on the low 32-bit. It generates > > > > > instructions where the virtual addresses have the high 32-bit to be zero. > > > > > > > > How are these assumptions hardcoded by GCC? Most of the instructions should be > > > > relocatable straight away, as most call/jump/branch instructions are > > > > RIP-relative. > > > > > > I think PIE is capable to use relative instructions well. mcmodel=large assumes > > > symbols can be anywhere. > > > > So if the numbers in your changelog and Kconfig text cannot be trusted, there's > > this description of the size impact which I suspect is less susceptible to > > measurement error: > > > > + The kernel and modules will generate slightly more assembly (1 to 2% > > + increase on the .text sections). The vmlinux binary will be > > + significantly smaller due to less relocations. > > > > ... but describing a 1-2% kernel text size increase as "slightly more assembly" > > shows a gratituous disregard to kernel code generation quality! In reality that's > > a huge size increase that in most cases will almost directly transfer to a 1-2% > > slowdown for kernel intense workloads. > > > > > > Where does that size increase come from, if PIE is capable of using relative > > instructins well? Does it come from the loss of a generic register and the > > resulting increase in register pressure, stack spills, etc.? > > I will try to gather more information on the size increase. The size > increase might be smaller with gcc 4.9 given performance was much > better. Coming back on this thread as I identified the root cause of the performance issue. My original performance testing was done with an Ubuntu generic configuration. This configuration has the CONFIG_FUNCTION_TRACER option which was incompatible with PIE. The tracer failed to replace the __fentry__ call by a nop slide on each traceable function because the instruction was not the one expected. If PIE is enabled, gcc generates a difference call instruction based on the GOT without checking the visibility options (basically call *__fentry__@GOTPCREL). With the fix for function tracing, the hackbench results have an average of +0.8 to +1.4% (from +8% to +10% before). With a default configuration, the numbers are closer to 0.8%. On the .text size, with gcc 4.9 I see +0.8% on default configuration and +1.180% on the ubuntu configuration. Next iteration should have an updated set of performance metrics (will try to use gcc 6.0 or higher) and incorporate the fix on function tracing. Let me know if you have questions and feedback. > > > > > So I'm still unhappy about this all, and about the attitude surrounding it. > > > > Thanks, > > > > Ingo > > > > > -- > Thomas -- Thomas