Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932919AbbLVQiw (ORCPT ); Tue, 22 Dec 2015 11:38:52 -0500 Received: from mail-qk0-f176.google.com ([209.85.220.176]:33832 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932079AbbLVQiv (ORCPT ); Tue, 22 Dec 2015 11:38:51 -0500 Message-ID: <1450802317.15572.102.camel@gmail.com> Subject: Re: [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX From: Daniel Micay To: kernel-hardening@lists.openwall.com, Laura Abbott Cc: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kees Cook Date: Tue, 22 Dec 2015 11:38:37 -0500 In-Reply-To: References: <1450755641-7856-1-git-send-email-laura@labbott.name> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-R9P+6EvZ3pLH2YzinrHb" X-Mailer: Evolution 3.18.3 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3774 Lines: 98 --=-R9P+6EvZ3pLH2YzinrHb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I am not sure what the point of this patchset is. We have a similar > effect > to sanitization already in the allocators through two mechanisms: The rationale was covered earlier. Are you responding to that or did you not see it? > 1. Slab poisoning > 2. Allocation with GFP_ZERO >=20 > I do not think we need a third one. You could accomplish your goals > much > easier without this code churn by either >=20 > 1. Improve the existing poisoning mechanism. Ensure that there are no > =C2=A0=C2=A0=C2=A0gaps. Security sensitive kernel slab caches can then be= created > with > =C2=A0=C2=A0=C2=A0the=C2=A0=C2=A0POISONING flag set. Maybe add a Kconfig = flag that enables > =C2=A0=C2=A0=C2=A0POISONING for each cache? What was the issue when you t= ried using > =C2=A0=C2=A0=C2=A0posining for sanitization? >=20 > 2. Add a mechanism that ensures that GFP_ZERO is set for each > allocation. > =C2=A0=C2=A0=C2=A0That way every object you retrieve is zeroed and thus y= ou have > implied > =C2=A0=C2=A0=C2=A0sanitization. This also can be done in a rather simple = way by > changing > =C2=A0=C2=A0=C2=A0the=C2=A0=C2=A0GFP_KERNEL etc constants to include __GF= P_ZERO depending on a > =C2=A0=C2=A0=C2=A0Kconfig option. Or add some runtime setting of the gfp = flags > somewhere. >=20 > Generally I would favor option #2 if you must have sanitization > because > that is the only option to really give you a deterministic content of > object on each allocation. Any half way measures would not work I > think. >=20 > Note also that most allocations are already either allocations that > zero > the content or they are immediately initializing the content of the > allocated object. After all the object is not really usable if the > content is random. You may be able to avoid this whole endeavor by > auditing the kernel for locations where the object is not initialized > after allocation. >=20 > Once one recognizes the above it seems that sanitization is pretty > useless. Its just another pass of writing zeroes before the allocator > or > uer of the allocated object sets up deterministic content of the > object or > -- in most cases -- zeroes it again. Sanitization isn't just to prevent leaks from usage of uninitialized data in later allocations. It's a mitigation for use-after-free (esp. if it's combined with some form of delayed freeing) and it reduces the lifetime of data. --=-R9P+6EvZ3pLH2YzinrHb 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 iQIcBAABCAAGBQJWeXyNAAoJEPnnEuWa9fIqjrYQAJaEzoGOlaw3y0rN4YRJU6+x Ua7hjSxAY7iMM7zKYWqbz5XCjkqagdOCCcBgDhoo0q2NX6u9FPkfF2tBzggacLhk GXrAXJf15dSv5zqfWlozyEmTGiuJSHDaYTibbGLrFoegXK5xSgSoCHiGpr1w2kXP xA+Poc2F+S4+wkoF1gLb9I2w/4yRDDsWDtHIkVVBV1Tl85IYAA8cTSBJ3jO/VEe7 DoB1H7XzRvqqc/qeJnU/vMHleR4DcW4bp5oCYDL9UfzgGSvkf8c0NUViPSY9lAfZ mYp6Y8tThRIoyONAHFPgUV9Rhe4ShBnRaoFCD1KO/LKRuFhOEfTGUQ6TRAYg7jgt 2dQJivBhBddKwKkGvw58IsOIDVkpAiqobWezrCbzIwvZCtyLi+MifBqmF6S75jCH KYVjua1Ks7iWxNGqsCNUUbu7dMQ3z4xkB4j9O0GRJnWcIbTouGL1ReKyrXHIBJeS zsTk+ElCaJntJGl2Gok0J8pgIvyXc13Kfblk+U5T3PcB11K6Gp/m1Sp4wWfz5mO6 +YP5WS1vZ/7g7FI5G/kUd8QPkcjkSDOlmRdV3QnYRSn7LYJThnF8P4buqi9iZ2e1 htC7VNwQIsAn6obkYgGQZ/XY6v6XHqJ96tmrGiiJNYsB7Y80HGkYXAt9QYZEpsWG FNTuTLKN3YMErcOpwmsJ =pRVv -----END PGP SIGNATURE----- --=-R9P+6EvZ3pLH2YzinrHb-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/