From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6D555CCA479 for ; Wed, 13 Jul 2022 16:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R84GgYWETGmT9X11S5Rx+VYZJ6QOyj++JKTH0jh9xng=; b=VFzc9lag/FiYbDht78NASpPqIi gMbgd1ZV+nsmVnAPVdDoBV+ARIlqsKIk/1fk5mFdC4Cj8ITqTvztXBhDrrtN6QIARP9Fb1VbDC4O+ yWr0pSso7SeInTnBRId8jYrrGIJlPJfxdQ1x2x/1BKrdaJKlvSxq2mea4dQrS8IpYXKF58fIzHH5z pBVAx3WYJkxJqytLKVOvsiA5gRS+1ymqbqqKhmh8/Vrwbldi/MWHtuNRv/y90JDzP3545D1napMnx kO/CNdxe3xE+xoZdms7nGblZMltLLdwKmIrrr+TuoeF/a5QBzMir8cz/D+1vBQk+ePzwvxPjz5Mu4 0uba5gQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBf03-005VoB-8a; Wed, 13 Jul 2022 16:14:07 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBf00-005VlY-Dr for linux-arm-kernel@lists.infradead.org; Wed, 13 Jul 2022 16:14:05 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DCF24B820DA; Wed, 13 Jul 2022 16:14:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52580C34114; Wed, 13 Jul 2022 16:14:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657728841; bh=DvjZSWjJSynzTljUk3T648bwZUpu+50b1mDXGdCiOTE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uts4chHNkesQy89lPW2WzTCNX5jezmkEYtgzFkqlT1NsNYaL6tP6TADy05RYUMBFX QrbjphlbHqTXXLVgcmcTPy03dlnIoLKkFJePkTzyHe8nj5u2Ru/iqcxQTDq9jA+2a/ LKWdwUWxkO2lsyj7F3BmffWOb8C/DM4TJSEhinkuJlcJ9crIQXuazKdz351biYvPh5 M2d+hdLLLhx+nONHBTYDmAwBgYXBOk8n7QiZeAUqo6nGJa8MRdZeK52tLMTu1GzJIi iCsTc1xR0PJ+Llf/c6o9jbbcv/bhrxfvwi75MoLJruNvf1Wz5h3JTphVkbrTqat7fb JuzlYofbruZUQ== Date: Wed, 13 Jul 2022 17:13:57 +0100 From: Mark Brown To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Kees Cook , peterz@infradead.org Subject: Re: [PATCH] lkdtm: cfi: add test for HW landing pad CFI Message-ID: References: <20220713151815.295520-1-mark.rutland@arm.com> MIME-Version: 1.0 In-Reply-To: <20220713151815.295520-1-mark.rutland@arm.com> X-Cookie: Positively no smoking. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220713_091404_633041_DEDF3BC6 X-CRM114-Status: GOOD ( 20.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6792547052278725088==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6792547052278725088== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WlxfRJozGZMblBhb" Content-Disposition: inline --WlxfRJozGZMblBhb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 13, 2022 at 04:18:15PM +0100, Mark Rutland wrote: > Some architectures have coarse-grained HW CFI schemes where indirect > branches must target a "landing pad" instruction (e.g. BTI on arm64, > ENDBR on x86). These prevent gadgetization of arbitrary portions of > functions. > Add a test which checks these work as expected. > For example, on arm64 HW with BTI this should result in a BTI exception > being taken: > +/* > + * This tries to call an indirect function with an address which is not a > + * function entry point. This should be caught by architectures with "landing > + * pad" instructions (e.g. BTI on arm64, or ENDBR on x86). > + */ > +static void lkdtm_CFI_FORWARD_LANDING_PAD(void) > +{ > + void (*func)(int *); > + > + func = (void *)((unsigned long)lkdtm_increment_void + 4); > + > + pr_info("Calling gadget address ...\n"); > + func(&called_count); > + > + pr_err("FAIL: survived gadget function call!\n"); > +} Incrementing the address by 4 here is the right number for arm64 and it looks like it's also right for the x86_64 ENDBR64 instruction but are we guaranteed that it'll do the right thing for other architectures, especially those with variable length instructions - couldn't we just get an illegal instruction exception due to ending up pointing at something that isn't the start of an instruction even if CFI isn't active? Not sure that worrying about that at this point isn't making perfect the enemy of good though, it could be dealt with later. Perhaps just put the offset behind a #define to make it a tiny bit more discoverable? --WlxfRJozGZMblBhb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmLO70QACgkQJNaLcl1U h9D14Af/Zaux0oRRA5qwI/epaZXUJgBNjGSvWjmGaLzusl+j5w6kPReW+Xk/+UxX Qg7eHQPhR6vOpOmDMlzKvtZHoKM/fiZVJQAGKVQZDJ85+uG5XsoA+wy/EuC69Hm3 Y96or99YmhNacpjh7Tnqmct5pAuiRiCw80vHBsCjJGgONwZPtjnY6163TgGKViKe cm5EZT4AKPCzAHep0bM+GpMMVF+O/n52Q+kOSVuAhG4HlkACf9uL/IGYI2LUufMk D7IprNWd+1FAwpcAwe1wVseLwco5sBboyeiit9KOKUVGOLVnnp7bZ0V+QbI7lKoe EeH5UfIBoQg4j6dz5h/zL4ncMDy0Hg== =57wd -----END PGP SIGNATURE----- --WlxfRJozGZMblBhb-- --===============6792547052278725088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6792547052278725088==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C7AEC43334 for ; Wed, 13 Jul 2022 16:14:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237158AbiGMQOH (ORCPT ); Wed, 13 Jul 2022 12:14:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236481AbiGMQOF (ORCPT ); Wed, 13 Jul 2022 12:14:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 244392CDCA for ; Wed, 13 Jul 2022 09:14:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D752CB820D8 for ; Wed, 13 Jul 2022 16:14:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52580C34114; Wed, 13 Jul 2022 16:14:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657728841; bh=DvjZSWjJSynzTljUk3T648bwZUpu+50b1mDXGdCiOTE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uts4chHNkesQy89lPW2WzTCNX5jezmkEYtgzFkqlT1NsNYaL6tP6TADy05RYUMBFX QrbjphlbHqTXXLVgcmcTPy03dlnIoLKkFJePkTzyHe8nj5u2Ru/iqcxQTDq9jA+2a/ LKWdwUWxkO2lsyj7F3BmffWOb8C/DM4TJSEhinkuJlcJ9crIQXuazKdz351biYvPh5 M2d+hdLLLhx+nONHBTYDmAwBgYXBOk8n7QiZeAUqo6nGJa8MRdZeK52tLMTu1GzJIi iCsTc1xR0PJ+Llf/c6o9jbbcv/bhrxfvwi75MoLJruNvf1Wz5h3JTphVkbrTqat7fb JuzlYofbruZUQ== Date: Wed, 13 Jul 2022 17:13:57 +0100 From: Mark Brown To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Kees Cook , peterz@infradead.org Subject: Re: [PATCH] lkdtm: cfi: add test for HW landing pad CFI Message-ID: References: <20220713151815.295520-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WlxfRJozGZMblBhb" Content-Disposition: inline In-Reply-To: <20220713151815.295520-1-mark.rutland@arm.com> X-Cookie: Positively no smoking. Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --WlxfRJozGZMblBhb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 13, 2022 at 04:18:15PM +0100, Mark Rutland wrote: > Some architectures have coarse-grained HW CFI schemes where indirect > branches must target a "landing pad" instruction (e.g. BTI on arm64, > ENDBR on x86). These prevent gadgetization of arbitrary portions of > functions. > Add a test which checks these work as expected. > For example, on arm64 HW with BTI this should result in a BTI exception > being taken: > +/* > + * This tries to call an indirect function with an address which is not a > + * function entry point. This should be caught by architectures with "landing > + * pad" instructions (e.g. BTI on arm64, or ENDBR on x86). > + */ > +static void lkdtm_CFI_FORWARD_LANDING_PAD(void) > +{ > + void (*func)(int *); > + > + func = (void *)((unsigned long)lkdtm_increment_void + 4); > + > + pr_info("Calling gadget address ...\n"); > + func(&called_count); > + > + pr_err("FAIL: survived gadget function call!\n"); > +} Incrementing the address by 4 here is the right number for arm64 and it looks like it's also right for the x86_64 ENDBR64 instruction but are we guaranteed that it'll do the right thing for other architectures, especially those with variable length instructions - couldn't we just get an illegal instruction exception due to ending up pointing at something that isn't the start of an instruction even if CFI isn't active? Not sure that worrying about that at this point isn't making perfect the enemy of good though, it could be dealt with later. Perhaps just put the offset behind a #define to make it a tiny bit more discoverable? --WlxfRJozGZMblBhb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmLO70QACgkQJNaLcl1U h9D14Af/Zaux0oRRA5qwI/epaZXUJgBNjGSvWjmGaLzusl+j5w6kPReW+Xk/+UxX Qg7eHQPhR6vOpOmDMlzKvtZHoKM/fiZVJQAGKVQZDJ85+uG5XsoA+wy/EuC69Hm3 Y96or99YmhNacpjh7Tnqmct5pAuiRiCw80vHBsCjJGgONwZPtjnY6163TgGKViKe cm5EZT4AKPCzAHep0bM+GpMMVF+O/n52Q+kOSVuAhG4HlkACf9uL/IGYI2LUufMk D7IprNWd+1FAwpcAwe1wVseLwco5sBboyeiit9KOKUVGOLVnnp7bZ0V+QbI7lKoe EeH5UfIBoQg4j6dz5h/zL4ncMDy0Hg== =57wd -----END PGP SIGNATURE----- --WlxfRJozGZMblBhb--