From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support Date: Tue, 21 Jun 2016 14:32:28 -0400 Message-ID: <1466533948.2756.56.camel@redhat.com> References: Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-JIDeOF8ZZyE1csowjY8T" Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: kernel-hardening@lists.openwall.com, Andy Lutomirski Cc: Jann Horn , Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens List-Id: linux-arch.vger.kernel.org --=-JIDeOF8ZZyE1csowjY8T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski > wrote: > >=C2=A0 > > I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc > > range. > > It has no in-tree users for non-fixed addresses right now. > What about the lack of pre-range guard page? That seems like a > critical feature for this. :) If VM_NO_GUARD is disallowed, and every vmalloc area has a guard area behind it, then every subsequent vmalloc area will have a guard page ahead of it. I think disallowing VM_NO_GUARD will be all that is required. The only thing we may want to verify on the architectures that we care about is that there is nothing mapped immediately before the start of the vmalloc range, otherwise the first vmalloced area will not have a guard page below it. I suspect all the 64 bit architectures are fine in that regard, with enormous gaps between kernel memory ranges. --=20 All Rights Reversed. --=-JIDeOF8ZZyE1csowjY8T 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 iQEcBAABCAAGBQJXaYg9AAoJEM553pKExN6DMgQH/AkJiDO6nYz4HDPcXzy6mKtQ P5YfvXRL6roj7l3lG5FQuwcPryPj+vy4HHyysPEvo9Sk8DABLDsvDO3a8QdbWrkm D2zFcrN3OaAN8IRXHPyhHgDrotBZ5AUkFiUzf4EP18kxML+AWZioifpM8XL5FvH6 YbZRKyNaDz5QZpB+5DIIjT/3ngU+2Cn71ZkreKJ9fSqVfnP4Ea+U+89CzHi9hxUr tC+eTPrgiJ281SBFQUCbs42WSpd7vfQtSk8Q2IxRCChKAyBhY8AVKH37+hYvOtgw H5jiIzbdOyDo5ofr01P0emLx/kEGyH4zURu8QCeJMxHB9XB86QVwHh4bc/RzkP4= =hL+a -----END PGP SIGNATURE----- --=-JIDeOF8ZZyE1csowjY8T-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:35938 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbcFUSoH (ORCPT ); Tue, 21 Jun 2016 14:44:07 -0400 Message-ID: <1466533948.2756.56.camel@redhat.com> Subject: Re: [kernel-hardening] Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support From: Rik van Riel Date: Tue, 21 Jun 2016 14:32:28 -0400 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-JIDeOF8ZZyE1csowjY8T" Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: kernel-hardening@lists.openwall.com, Andy Lutomirski Cc: Jann Horn , Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens Message-ID: <20160621183228.Va1fmqkrM_aSGccC1Zoz4dJgv6nkKh-5S1RWUWDP1vw@z> --=-JIDeOF8ZZyE1csowjY8T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski > wrote: > >=C2=A0 > > I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc > > range. > > It has no in-tree users for non-fixed addresses right now. > What about the lack of pre-range guard page? That seems like a > critical feature for this. :) If VM_NO_GUARD is disallowed, and every vmalloc area has a guard area behind it, then every subsequent vmalloc area will have a guard page ahead of it. I think disallowing VM_NO_GUARD will be all that is required. The only thing we may want to verify on the architectures that we care about is that there is nothing mapped immediately before the start of the vmalloc range, otherwise the first vmalloced area will not have a guard page below it. I suspect all the 64 bit architectures are fine in that regard, with enormous gaps between kernel memory ranges. --=20 All Rights Reversed. --=-JIDeOF8ZZyE1csowjY8T 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 iQEcBAABCAAGBQJXaYg9AAoJEM553pKExN6DMgQH/AkJiDO6nYz4HDPcXzy6mKtQ P5YfvXRL6roj7l3lG5FQuwcPryPj+vy4HHyysPEvo9Sk8DABLDsvDO3a8QdbWrkm D2zFcrN3OaAN8IRXHPyhHgDrotBZ5AUkFiUzf4EP18kxML+AWZioifpM8XL5FvH6 YbZRKyNaDz5QZpB+5DIIjT/3ngU+2Cn71ZkreKJ9fSqVfnP4Ea+U+89CzHi9hxUr tC+eTPrgiJ281SBFQUCbs42WSpd7vfQtSk8Q2IxRCChKAyBhY8AVKH37+hYvOtgw H5jiIzbdOyDo5ofr01P0emLx/kEGyH4zURu8QCeJMxHB9XB86QVwHh4bc/RzkP4= =hL+a -----END PGP SIGNATURE----- --=-JIDeOF8ZZyE1csowjY8T--