From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752168AbcFUSEO (ORCPT ); Tue, 21 Jun 2016 14:04:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39298 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbcFUSEL (ORCPT ); Tue, 21 Jun 2016 14:04:11 -0400 Message-ID: <1466532133.2756.50.camel@redhat.com> Subject: Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) From: Rik van Riel To: kernel-hardening@lists.openwall.com, Arnd Bergmann Cc: Andy Lutomirski , "x86@kernel.org" , LKML , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens Date: Tue, 21 Jun 2016 14:02:13 -0400 In-Reply-To: References: <13212319.WrhLzgRA6Z@wuerfel> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-CorTQSSXHM2WOtKrQ0Sl" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 21 Jun 2016 18:02:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-CorTQSSXHM2WOtKrQ0Sl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > >=20 > > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: > > >=20 > > >=20 > > > On my laptop, this adds about 1.5=C2=B5s of overhead to task creation= , > > > which seems to be mainly caused by vmalloc inefficiently > > > allocating > > > individual pages even when a higher-order page is available on > > > the > > > freelist. > > Would it help to have a fixed virtual address for the stack instead > > and map the current stack to that during a task switch, similar to > > how we handle fixmap pages? > >=20 > > That would of course trade the allocation overhead for a task > > switch > > overhead, which may be better or worse. It would also give > > "current" > > a constant address, which may give a small performance advantage > > but may also introduce a new attack vector unless we randomize it > > again. > Right: we don't want a fixed address. That makes attacks WAY easier. Does that imply we might want the per-cpu cache of these stacks to be larger than one, in order to introduce some more randomness after an attacker crashed an ASLRed program looking for ROP gadgets, and the next one is spawned? :) --=20 All Rights Reversed. --=-CorTQSSXHM2WOtKrQ0Sl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXaYElAAoJEM553pKExN6Dd1IH/26D9y8/CCeKr35zps5ADJPk xdGDss78w8Dks+PT0yUsqCXZBlvKdmJAxveAx+nME2RQ/hvcanGAFvoJf4EunSJv UWtkErANVA9mm6gtVqguW276BnkNdv0mjPfF5oGuiptmHfmjE0Oc+0HyuX4xcj4G rN1Nw+fZtJIgCZn/8HCkHF2q5jladxfZneJpI9wsEwbUBBzzciqQbxAJr11JHdxm 1CmHq36G3PX3BssWgx7bb79sKnyaOpccfuBFuUK4d5mMQ0kyd2q2YauTiqxECcm7 GCj2Zx9lDnA3rs1vxcmcr5+0q0osYKh+NU/H9rqDkoMc7B5qHSW9kSyiDE34jDE= =6XiW -----END PGP SIGNATURE----- --=-CorTQSSXHM2WOtKrQ0Sl-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Tue, 21 Jun 2016 14:02:13 -0400 Message-ID: <1466532133.2756.50.camel@redhat.com> References: <13212319.WrhLzgRA6Z@wuerfel> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-CorTQSSXHM2WOtKrQ0Sl" Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: kernel-hardening@lists.openwall.com, Arnd Bergmann Cc: Andy Lutomirski , "x86@kernel.org" , LKML , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens List-Id: linux-arch.vger.kernel.org --=-CorTQSSXHM2WOtKrQ0Sl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > >=20 > > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: > > >=20 > > >=20 > > > On my laptop, this adds about 1.5=C2=B5s of overhead to task creation= , > > > which seems to be mainly caused by vmalloc inefficiently > > > allocating > > > individual pages even when a higher-order page is available on > > > the > > > freelist. > > Would it help to have a fixed virtual address for the stack instead > > and map the current stack to that during a task switch, similar to > > how we handle fixmap pages? > >=20 > > That would of course trade the allocation overhead for a task > > switch > > overhead, which may be better or worse. It would also give > > "current" > > a constant address, which may give a small performance advantage > > but may also introduce a new attack vector unless we randomize it > > again. > Right: we don't want a fixed address. That makes attacks WAY easier. Does that imply we might want the per-cpu cache of these stacks to be larger than one, in order to introduce some more randomness after an attacker crashed an ASLRed program looking for ROP gadgets, and the next one is spawned? :) --=20 All Rights Reversed. --=-CorTQSSXHM2WOtKrQ0Sl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXaYElAAoJEM553pKExN6Dd1IH/26D9y8/CCeKr35zps5ADJPk xdGDss78w8Dks+PT0yUsqCXZBlvKdmJAxveAx+nME2RQ/hvcanGAFvoJf4EunSJv UWtkErANVA9mm6gtVqguW276BnkNdv0mjPfF5oGuiptmHfmjE0Oc+0HyuX4xcj4G rN1Nw+fZtJIgCZn/8HCkHF2q5jladxfZneJpI9wsEwbUBBzzciqQbxAJr11JHdxm 1CmHq36G3PX3BssWgx7bb79sKnyaOpccfuBFuUK4d5mMQ0kyd2q2YauTiqxECcm7 GCj2Zx9lDnA3rs1vxcmcr5+0q0osYKh+NU/H9rqDkoMc7B5qHSW9kSyiDE34jDE= =6XiW -----END PGP SIGNATURE----- --=-CorTQSSXHM2WOtKrQ0Sl--