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 D9C3FD17129 for ; Mon, 21 Oct 2024 19:43:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From: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=botyNfe3VB7/BUtvvCBHxxnrx4A1zUryJoPGS0dtrVY=; b=skEux2QsxUs+XL3Lxu7hsygvUc TMN4hyp5gedPh8OGh2UpAqRGzkG3oLdV6RgfSFO4oRVWJ66+QT0xthEgPE1FTPBDTmY6cwNSJ+aBd j3hItbhT5vwULNdTgbeigVN8fQCBJBQj9EYOOsc8gnZonuHSRozhyVdJXETFfRrKkmEmJw6mzp1g1 GqIuioupx6dnRVAsS0psKm27okFg4sxyc0vv1IGge3zbjidEOhxfYglwFdGAkSkRFPFjCeoNEXKb0 aChYNd+XTvR3hSC093Vq3VZsdTH2Vepxf2J6IMWaI+q0MjPI4PhErt/qOkw4z/uJM4Ivm95YspMEW 5STqyXKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2yJP-00000008Tzi-2TSw; Mon, 21 Oct 2024 19:43:31 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t2yGe-00000008TQk-3Trw for linux-arm-kernel@lists.infradead.org; Mon, 21 Oct 2024 19:40:42 +0000 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5c99be0a4bbso6541129a12.2 for ; Mon, 21 Oct 2024 12:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729539638; x=1730144438; darn=lists.infradead.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=botyNfe3VB7/BUtvvCBHxxnrx4A1zUryJoPGS0dtrVY=; b=Eslzk2bCpM8MtJ9TVXl5jkdEeOP4nPvwu/fKHUZzJ8F8HRJo+w++9/Q7xusU3CBbLB IIb88DMxEFBUF7C1vSDnerAmOkas5Oi35b2BiEOY05kpGq6yPkFnqLJ3OcnE4PKMq6V7 YKx5B9joI4chzSr6Z3aaF88IiWhsp69Wze180F6J85j82ntVK8ZeafsJdm1yDW7fZJti OcykHsmB7JVslMjwFkdSOeNN1GeY69A7Ej2DTX307iNWEmmQAyu1oaWphOjDfVMSDOgv ZxZaIdbodLemh0uyQyuoC2izS4d5YwqXS/zuY6zRUi3k/dH3Ehcb23t1MyR50Exkj6g+ b1vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729539638; x=1730144438; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=botyNfe3VB7/BUtvvCBHxxnrx4A1zUryJoPGS0dtrVY=; b=NvLHKdrHPUGZje5x3b4o1KgtQwe5Whc9yxl+2s9zSIy6RGs/xfkJwBiiKFq/jtwlQS auxheA7SK3uwmw+u0ic1ir6goDTHFjT+kL4KXwxwhWUGgtbo+EkTZN+2/irTIEhy8v8p 9bdRtMHd6Ou59pAavF8P+T7+y+emR+DlNVRxQhKJ/jJUbXkE7GyBPfwWXBNVKBMCBi0j Yqth7f9AGyDEsstW+360xVfvS/qSvyV1dcwm+2lDg9HPt8ZVS63OGeX4NGmb/RQb6fWN xeU3KDEKXdPw2qc2tKKHTrn5SCxoWB3zra3Ghbt1A5Br14d3sPGnlOxHyCEuapGWyzZE Sljw== X-Forwarded-Encrypted: i=1; AJvYcCUAs8FcQK2KuZqphvCscV/4iHJHgAk8SXD/XzPWFek7/0YDtNH2YpzCmPqXVXOggaoGB7jn7JNgKkO4skp4llQQ@lists.infradead.org X-Gm-Message-State: AOJu0YxWJvd0GUrNs9GH2HO3AGdNN9cz/k8bEehWYgvoGQUNTqbmgDRm lUiHhQiod43lCaEF+3yeDONc7iOp1ZPID19gwJg817aEXcEnz1ZvZvelyWqkixM= X-Google-Smtp-Source: AGHT+IEM/I0qlAuX/kgLUJyBj9Afk6z+i9eZckKY0kQ3UZHPYFbNDLbcFVk8PnNFLD+gUpqQ3TGScA== X-Received: by 2002:a17:907:1c98:b0:a9a:1792:f05 with SMTP id a640c23a62f3a-a9aa892cc34mr105653066b.31.1729539637321; Mon, 21 Oct 2024 12:40:37 -0700 (PDT) Received: from localhost (54-240-197-231.amazon.com. [54.240.197.231]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91370e91sm243650366b.123.2024.10.21.12.40.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Oct 2024 12:40:36 -0700 (PDT) From: Puranjay Mohan To: Mark Rutland , linux-arm-kernel@lists.infradead.org Cc: broonie@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, mbenes@suse.cz, will@kernel.org Subject: Re: [PATCH] arm64: preserve pt_regs::stackframe during exec*() In-Reply-To: <20241021164456.2275285-1-mark.rutland@arm.com> References: <20241021164456.2275285-1-mark.rutland@arm.com> Date: Mon, 21 Oct 2024 19:40:31 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241021_124040_898989_80AEC5C7 X-CRM114-Status: GOOD ( 27.97 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --=-=-= Content-Type: text/plain Mark Rutland writes: > When performing an exec*(), there's a transient period before the return > to userspace where any stacktrace will result in a warning triggered by > kunwind_next_frame_record_meta() encountering a struct frame_record_meta > with an unknown type. This can be seen fairly reliably by enabling KASAN > or KFENCE, e.g. > > | WARNING: CPU: 3 PID: 143 at arch/arm64/kernel/stacktrace.c:223 arch_stack_walk+0x264/0x3b0 > | Modules linked in: > | CPU: 3 UID: 0 PID: 143 Comm: login Not tainted 6.12.0-rc2-00010-g0f0b9a3f6a50 #1 > | Hardware name: linux,dummy-virt (DT) > | pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) > | pc : arch_stack_walk+0x264/0x3b0 > | lr : arch_stack_walk+0x1ec/0x3b0 > | sp : ffff80008060b970 > | x29: ffff80008060ba10 x28: fff00000051133c0 x27: 0000000000000000 > | x26: 0000000000000000 x25: 0000000000000000 x24: fff000007fe84000 > | x23: ffff9d1b3c940af0 x22: 0000000000000000 x21: fff00000051133c0 > | x20: ffff80008060ba50 x19: ffff9d1b3c9408e0 x18: 0000000000000014 > | x17: 000000006d50da47 x16: 000000008e3f265e x15: fff0000004e8bf40 > | x14: 0000ffffc5e50e48 x13: 000000000000000f x12: 0000ffffc5e50fed > | x11: 000000000000001f x10: 000018007f8bffff x9 : 0000000000000000 > | x8 : ffff80008060b9c0 x7 : ffff80008060bfd8 x6 : ffff80008060ba80 > | x5 : ffff80008060ba00 x4 : ffff80008060c000 x3 : ffff80008060bff0 > | x2 : 0000000000000018 x1 : ffff80008060bfd8 x0 : 0000000000000000 > | Call trace: > | arch_stack_walk+0x264/0x3b0 (P) > | arch_stack_walk+0x1ec/0x3b0 (L) > | stack_trace_save+0x50/0x80 > | metadata_update_state+0x98/0xa0 > | kfence_guarded_free+0xec/0x2c4 > | __kfence_free+0x50/0x100 > | kmem_cache_free+0x1a4/0x37c > | putname+0x9c/0xc0 > | do_execveat_common.isra.0+0xf0/0x1e4 > | __arm64_sys_execve+0x40/0x60 > | invoke_syscall+0x48/0x104 > | el0_svc_common.constprop.0+0x40/0xe0 > | do_el0_svc+0x1c/0x28 > | el0_svc+0x34/0xe0 > | el0t_64_sync_handler+0x120/0x12c > | el0t_64_sync+0x198/0x19c > > This happens because start_thread_common() zeroes the entirety of > current_pt_regs(), including pt_regs::stackframe::type, changing this > from FRAME_META_TYPE_FINAL to 0 and making the final record invalid. > The stacktrace code will reject this until the next return to userspace, > where a subsequent exception entry will reinitialize the type to > FRAME_META_TYPE_FINAL. > > This zeroing wasn't a problem prior to commit: > > 0f0b9a3f6a50fa36 ("arm64: stacktrace: unwind exception boundaries") > > ... as before that commit the stacktrace code only expected the final > pt_regs::stackframe to contain zeroes, which was unchanged by > start_thread_common(). > > A stacktrace could occur at any time, either due to instrumentation or > an exception, and so start_thread_common() must ensure that > pt_regs::stackframe is always valid. > > Fix this by changing the way start_thread_common() zeroes and > reinitializes the pt_regs fields: > > * The '{regs,pc,pstate}' fields are initialized in one go via a struct > assignment to the user_regs, with start_thread() and > compat_start_thread() modified to pass 'pstate' into > start_thread_common(). > > * The 'sp' and 'compat_sp' fields are zeroed by the struct assignment in > start_thread_common(), and subsequently overwritten in start_thread() > and compat_start_thread respectively, matching existing behaviour. > > * The 'syscallno' field is implicitly preserved while the 'orig_x0' > field is explicitly zeroed, maintaining existing ABI. > > * The 'pmr' field is explicitly initialized, as necessary for an exec*() > from a kernel thread, matching existing behaviour. > > * The 'stackframe' field is implicitly preserved, with a new comment and > some assertions to ensure we don't accidentally break this in future. > > * All other fields are implicitly preserved, and should have no > functional impact: > > - 'sdei_ttbr1' is only used for SDEI exception entry/exit, and we > never exec*() inside an SDEI handler. > > - 'lockdep_hardirqs' and 'exit_rcu' are only used for EL1 exception > entry/exit, and we never exec*() inside an EL1 exception handler. > > While updating compat_start_thread() to pass 'pstate' into > start_thread_common(), I've also updated the logic to remove the > ifdeffery, replacing: > > | #ifdef __AARCH64EB__ > | regs->pstate |= PSR_AA32_E_BIT; > | #endif > > ... with: > > | if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) > | pstate |= PSR_AA32_E_BIT; > > ... which should be functionally equivalent, and matches our preferred > code style. > > Fixes: 0f0b9a3f6a50fa36 ("arm64: stacktrace: unwind exception boundaries") > Signed-off-by: Mark Rutland I tested this with KVM on an AWS graviton metal host. The warning is gone now. Tested-by: Puranjay Mohan Reviewed-by: Puranjay Mohan Thanks, Puranjay --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIsEARYKADMWIQQ3wHGvVs/5bdl78BKwwPkjG3B2nQUCZxauMBUccHVyYW5qYXkx MkBnbWFpbC5jb20ACgkQsMD5Ixtwdp0q2gD8D2qRSe37fseGrWynMJ/iUat1zUpz C/lssd2HG8qFPzcBAOo/ZYneNdCws2PDV7IcsZaE03cuZsdcFiEg6UszLIMH =d8x4 -----END PGP SIGNATURE----- --=-=-=--