From: Pavel Machek Subject: Re: Re: x86: PIE support and option to extend KASLR randomization Date: Mon, 28 Aug 2017 11:59:23 +0200 Message-ID: <20170828095922.GA18012@amd> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Cc: Ingo Molnar , Thomas Garnier , 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 , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel , Tom Lendacky , Andy Lutomirski , Borislav Petkov , Brian Gerst , "Kirill A . Shutemov" , "Rafael J . Wysocki" , Len Brown , Te To: Boris Lukashev Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: List-Id: linux-crypto.vger.kernel.org --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > + 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 a= ssembly" > > shows a gratituous disregard to kernel code generation quality! In real= ity that's > > a huge size increase that in most cases will almost directly transfer t= o a 1-2% > > slowdown for kernel intense workloads. > > > > Where does that size increase come from, if PIE is capable of using rel= ative > > instructins well? Does it come from the loss of a generic register and = the > > resulting increase in register pressure, stack spills, etc.? > > > > So I'm still unhappy about this all, and about the attitude surrounding= it. >=20 > Is the expectation then to have security functions also decrease size > and operational latency? Seems a bit unrealistic if so. > 1-2% performance hit on systems which have become at least several > hundred % faster over recent years is not a significant performance > regression compared to the baseline before. We are probably willing to trade security for 2% performance impact... if you can show that same security advantage can't be achieved without the impact (and it is opt-in and documented and so on). Kernel is not really a bottleneck for many people. For me, even CPUs are not bottleneck, disk is. But what is not okay is "hey, this is security, I can slow things down. Merge it, because... security!". Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlmj6XoACgkQMOfwapXb+vKoAQCgxGEhuA4qK9TP8Gv7ryOV8XoZ v6QAoLsAwustidDVeUK6439ZUkIuqVMe =EZIN -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--