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 X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD420C433E0 for ; Mon, 18 May 2020 08:10:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A66EA207D8 for ; Mon, 18 May 2020 08:10:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=aj.id.au header.i=@aj.id.au header.b="qqCr/U7Z"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="T9C0di6f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727109AbgERIK6 (ORCPT ); Mon, 18 May 2020 04:10:58 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:41913 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726489AbgERIK5 (ORCPT ); Mon, 18 May 2020 04:10:57 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB0805C0135; Mon, 18 May 2020 04:10:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Mon, 18 May 2020 04:10:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=0VCyxFvAMhgusgpYr5rZXUJVhIUn8Js Ts3zpGGtk/U0=; b=qqCr/U7ZsqicykMchNolnowqKvxzNY/evSBODVQQ7E0w/oB d/qF7NUTRhCbO/ZX8y3WxrsdPhJ+mA46E3n/C0RhbrrEfU/akHwmt+Jj1+QiuXVi J8w1vh3af7RD1euv7ZD/seRCYYDudB/9P8UOydCt6XxynGzH0YtPWAZ1XqU8KrXb hl9J0gn/iG/wbWXgZOJRnVlzF9zgYS+HnmDzPrX3U3BLlmZlIz0QISWPFCEdzhzi CAkD5/41cS0oAu5oLU8mCrr2p0D0bIDTXFXv/UBYv8w8HDOPuKiONS0gbK+c9LrV r5B8N1+OnJ2QtIzAipWiTPIeZnMEVGZEUuSRWcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0VCyxF vAMhgusgpYr5rZXUJVhIUn8JsTs3zpGGtk/U0=; b=T9C0di6fpbvAhkF2JLufwu fYCXmSMEM+NSdwzWW2JnJKDNTD3rHRiwGVwCGxxegyu/g0m3qXrRJa7ppJioeMOq ku4lbGzoVn9zfs5f0OupupdyOl5sUr+1qPqowvGj1iRHy3JL769SgO9ZpneHeMe2 0a4U9m8uwI72TSw/OUNGW++XAYO/U7eMpM+RqkHNPQPKisZiU/G/Sw9iutelNIxJ LBSRnfbi+hZJ+8Befupo5Kiyec0t2KxoGzSUMw9Fu6yaFG9q5EB6vqcqZlw1m9IA bfWIs5Dgv76MLPsadpY1VOPBzjtSzmqoRrI7iMj8IVo+fcqhKgr/8cBgU57D1YfA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddthedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetnhgu rhgvficulfgvfhhfvghrhidfuceorghnughrvgifsegrjhdrihgurdgruheqnecuggftrf grthhtvghrnhepuddttdekueeggedvtddtueekiedutdfguedutdefieeuteefieelteet vddthfeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvgifsegrjhdrihgurdgruh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 231EAE00B3; Mon, 18 May 2020 04:10:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200517160227.GU1551@shell.armlinux.org.uk> References: <20200517153959.293224-1-andrew@aj.id.au> <20200517160227.GU1551@shell.armlinux.org.uk> Date: Mon, 18 May 2020 17:40:31 +0930 From: "Andrew Jeffery" To: "Russell King" Cc: linux-arm-kernel@lists.infradead.org, "Kees Cook" , "Masami Hiramatsu" , labbott@redhat.com, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org Subject: =?UTF-8?Q?Re:_[PATCH]_ARM:_kprobes:_Avoid_fortify=5Fpanic()_when_copying?= =?UTF-8?Q?_optprobe_template?= Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 May 2020, at 01:32, Russell King - ARM Linux admin wrote: > On Mon, May 18, 2020 at 01:09:59AM +0930, Andrew Jeffery wrote: > > Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads > > to a panic in memcpy() when injecting a kprobe despite the fixes found > > in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with > > FORTIFY_SOURCE") and commit 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: > > optimized kprobes illegal instruction"). > > > > arch/arm/include/asm/kprobes.h effectively declares > > the target type of the optprobe_template_entry assembly label as a u32, > > which leads memcpy()'s __builtin_object_size() call to determine that > > the pointed-to object is of size four. In practical terms the symbol is > > used as a handle for the optimised probe assembly template that is at > > least 96 bytes in size. The symbol's use despite its type blows up the > > memcpy() in ARM's arch_prepare_optimized_kprobe() with a false-positive > > fortify_panic() when it should instead copy the optimised probe template > > into place. > > > > As mentioned, a couple of attempts have been made to address the issue > > by casting a pointer to optprobe_template_entry before providing it to > > memcpy(), however gccs such as Ubuntu 20.04's arm-linux-gnueabi-gcc > > 9.3.0 (Ubuntu 9.3.0-10ubuntu1) see through these efforts. > > > > Squash the false-positive by aliasing the template assembly with a new > > symbol 'arm_optprobe_template'; declare it as a function object and > > pass the function object as the argument to memcpy() such that > > __builtin_object_size() cannot immediately determine the object size. > > > > Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE") > > Fixes: 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction") > > Signed-off-by: Andrew Jeffery > > --- > > arch/arm/include/asm/kprobes.h | 7 +++++++ > > arch/arm/probes/kprobes/opt-arm.c | 4 +++- > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h > > index 213607a1f45c..94db8bf25f9c 100644 > > --- a/arch/arm/include/asm/kprobes.h > > +++ b/arch/arm/include/asm/kprobes.h > > @@ -43,6 +43,13 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr); > > int kprobe_exceptions_notify(struct notifier_block *self, > > unsigned long val, void *data); > > > > +/* > > + * The optprobe template buffer is not anything that should be called directly, > > + * however describe it as a function to give ourselves a handle to it that > > + * bypasses CONFIG_FORTIFY_SOURCE=y sanity checks in memcpy(). > > + */ > > +extern __visible void arm_optprobe_template(void); > > Does this really need to be globally visible to anything that happens > to include this header? > > While we may abhor "extern" declarations and prototypes in .c files, it > seems to me to be entirely reasonable for this to live in opt-arm.c and > remove the .global for this symbol, thereby making this symbol local to > opt-arm.c You are right, exposing it globally was unnecessary, I got caught up poking at the other symbols. But I think we should go with Kees' patch instead. Thanks for the quick feedback. Andrew 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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC44FC433DF for ; Mon, 18 May 2020 08:11:04 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 9CCA6207ED for ; Mon, 18 May 2020 08:11:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Yi70Y//t"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=aj.id.au header.i=@aj.id.au header.b="qqCr/U7Z"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="T9C0di6f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CCA6207ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HS/G9uL+rM6i2TU8LGddVZfCFmDuyEogo0XNF7jTjas=; b=Yi70Y//tV4joUR S886Ftat98gfWo13SBlxFtT8zDtxw+it5Zu5oYmkf87QA7h6eT9vLoujl17iobsLb9K+KdPMDr62H c4x/H+eTmYjlpEm85PrGvscoDIfHz41w4m+qqyLyTvpDgKCupIkkU2KCqHNWkJir50sKQZEHbguzE e/BV6RpMBdRcR8w3GOL5WrWcmlkC96FQ6/xF68HN5t2o7Q+fpd7flMImPST3zcuLGeluNLL9oRu5R e4yvy8MXFDdbhjzwag4GHB1m4hiy/MXnRK13JGqAGs4XYDn49vIvYz3sxhI12AVadvMTXOV1SZMGz OaN5iPeA5lQbTjZisUNg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jaarX-0001t3-2X; Mon, 18 May 2020 08:11:03 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jaarT-0001sI-Oj for linux-arm-kernel@lists.infradead.org; Mon, 18 May 2020 08:11:01 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB0805C0135; Mon, 18 May 2020 04:10:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Mon, 18 May 2020 04:10:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=0VCyxFvAMhgusgpYr5rZXUJVhIUn8Js Ts3zpGGtk/U0=; b=qqCr/U7ZsqicykMchNolnowqKvxzNY/evSBODVQQ7E0w/oB d/qF7NUTRhCbO/ZX8y3WxrsdPhJ+mA46E3n/C0RhbrrEfU/akHwmt+Jj1+QiuXVi J8w1vh3af7RD1euv7ZD/seRCYYDudB/9P8UOydCt6XxynGzH0YtPWAZ1XqU8KrXb hl9J0gn/iG/wbWXgZOJRnVlzF9zgYS+HnmDzPrX3U3BLlmZlIz0QISWPFCEdzhzi CAkD5/41cS0oAu5oLU8mCrr2p0D0bIDTXFXv/UBYv8w8HDOPuKiONS0gbK+c9LrV r5B8N1+OnJ2QtIzAipWiTPIeZnMEVGZEUuSRWcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0VCyxF vAMhgusgpYr5rZXUJVhIUn8JsTs3zpGGtk/U0=; b=T9C0di6fpbvAhkF2JLufwu fYCXmSMEM+NSdwzWW2JnJKDNTD3rHRiwGVwCGxxegyu/g0m3qXrRJa7ppJioeMOq ku4lbGzoVn9zfs5f0OupupdyOl5sUr+1qPqowvGj1iRHy3JL769SgO9ZpneHeMe2 0a4U9m8uwI72TSw/OUNGW++XAYO/U7eMpM+RqkHNPQPKisZiU/G/Sw9iutelNIxJ LBSRnfbi+hZJ+8Befupo5Kiyec0t2KxoGzSUMw9Fu6yaFG9q5EB6vqcqZlw1m9IA bfWIs5Dgv76MLPsadpY1VOPBzjtSzmqoRrI7iMj8IVo+fcqhKgr/8cBgU57D1YfA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddthedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetnhgu rhgvficulfgvfhhfvghrhidfuceorghnughrvgifsegrjhdrihgurdgruheqnecuggftrf grthhtvghrnhepuddttdekueeggedvtddtueekiedutdfguedutdefieeuteefieelteet vddthfeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvgifsegrjhdrihgurdgruh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 231EAE00B3; Mon, 18 May 2020 04:10:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200517160227.GU1551@shell.armlinux.org.uk> References: <20200517153959.293224-1-andrew@aj.id.au> <20200517160227.GU1551@shell.armlinux.org.uk> Date: Mon, 18 May 2020 17:40:31 +0930 From: "Andrew Jeffery" To: "Russell King" Subject: =?UTF-8?Q?Re:_[PATCH]_ARM:_kprobes:_Avoid_fortify=5Fpanic()_when_copying?= =?UTF-8?Q?_optprobe_template?= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200518_011100_051393_BC0A7C8B X-CRM114-Status: GOOD ( 22.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kees Cook , linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, Masami Hiramatsu , labbott@redhat.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 18 May 2020, at 01:32, Russell King - ARM Linux admin wrote: > On Mon, May 18, 2020 at 01:09:59AM +0930, Andrew Jeffery wrote: > > Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads > > to a panic in memcpy() when injecting a kprobe despite the fixes found > > in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with > > FORTIFY_SOURCE") and commit 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: > > optimized kprobes illegal instruction"). > > > > arch/arm/include/asm/kprobes.h effectively declares > > the target type of the optprobe_template_entry assembly label as a u32, > > which leads memcpy()'s __builtin_object_size() call to determine that > > the pointed-to object is of size four. In practical terms the symbol is > > used as a handle for the optimised probe assembly template that is at > > least 96 bytes in size. The symbol's use despite its type blows up the > > memcpy() in ARM's arch_prepare_optimized_kprobe() with a false-positive > > fortify_panic() when it should instead copy the optimised probe template > > into place. > > > > As mentioned, a couple of attempts have been made to address the issue > > by casting a pointer to optprobe_template_entry before providing it to > > memcpy(), however gccs such as Ubuntu 20.04's arm-linux-gnueabi-gcc > > 9.3.0 (Ubuntu 9.3.0-10ubuntu1) see through these efforts. > > > > Squash the false-positive by aliasing the template assembly with a new > > symbol 'arm_optprobe_template'; declare it as a function object and > > pass the function object as the argument to memcpy() such that > > __builtin_object_size() cannot immediately determine the object size. > > > > Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE") > > Fixes: 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction") > > Signed-off-by: Andrew Jeffery > > --- > > arch/arm/include/asm/kprobes.h | 7 +++++++ > > arch/arm/probes/kprobes/opt-arm.c | 4 +++- > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h > > index 213607a1f45c..94db8bf25f9c 100644 > > --- a/arch/arm/include/asm/kprobes.h > > +++ b/arch/arm/include/asm/kprobes.h > > @@ -43,6 +43,13 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr); > > int kprobe_exceptions_notify(struct notifier_block *self, > > unsigned long val, void *data); > > > > +/* > > + * The optprobe template buffer is not anything that should be called directly, > > + * however describe it as a function to give ourselves a handle to it that > > + * bypasses CONFIG_FORTIFY_SOURCE=y sanity checks in memcpy(). > > + */ > > +extern __visible void arm_optprobe_template(void); > > Does this really need to be globally visible to anything that happens > to include this header? > > While we may abhor "extern" declarations and prototypes in .c files, it > seems to me to be entirely reasonable for this to live in opt-arm.c and > remove the .global for this symbol, thereby making this symbol local to > opt-arm.c You are right, exposing it globally was unnecessary, I got caught up poking at the other symbols. But I think we should go with Kees' patch instead. Thanks for the quick feedback. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel