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 CA081C04FE0 for ; Wed, 9 Aug 2023 19:48:24 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc: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=pKHPRsrgav2Mgw6uY0rbGxykNIPRi/28PxxMogFL0uI=; b=xIgBwPzSTWQPSB YDyVjAP3j5yGIXQb4bRuJZY8Oi4c3LD2mLn23/2dSE51D0YtRhuPapVO+tv48kqnylVDMVu2iElLP CzjUVHQtK1o0lSXyY6DNCYMyzCF+X30DYKOTauPIKK/rFubK4iil2yo5kXwKNgJYetTCQEOhsw667 fTDoeN9fduCPW3gHRwUvua0NQD+MDsJ6i7Sgn+9awLaWbA56xGtx1PGqWPD+O7m6S7mIoBf8meaHz lYdtaUR28CQLk9A1XGFuCw4BM8DtI28kndx6HNQTCKeVuNFGkrDIWWIFbXe9h1IpcE+VDghVGXn55 5Ikv8Vm9mVVJhShd93JQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qTpA3-005lc3-0J; Wed, 09 Aug 2023 19:48:03 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qTp9y-005laR-0S for linux-arm-kernel@lists.infradead.org; Wed, 09 Aug 2023 19:48:01 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8BFF764766; Wed, 9 Aug 2023 19:47:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A67FC433CA; Wed, 9 Aug 2023 19:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691610477; bh=LVWmFLNlFsqLy7e1BUA70TvOsNkzKB2qYX+hUuhwmhQ=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=KkJbC2mVitbMfBbw0T5skIwv+Jr4WRiscTx7RhGBEORiBNRkDnfTaZxLTZGkZZT3w 1TZCcu+TJXXVq4X+ClEywv7Yq6gNFL+sPLijsPWcvqu0fnQel7IqpVkklW88wedsfZ TbeMaJNzS+Q5WqLsrN9wrqPMxjzS0gFMQ8SygqiFo7fwamNMszpad3CSBxNL3G/90/ Xs7i8/LS1RNdWsFjXWNDC4l9J//6eKVRELRJojC8uF7sHYXfAlOcbXNJveiOxFXijR xm/Vy2EU1zcR9XzCUn/I7K4Z+TMUHww0vS3Cm0SmmjAAf4Z82CVcMDdaYrrAC56ZVu Es+sPe8QFv7uw== Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 764B227C0054; Wed, 9 Aug 2023 15:47:55 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 09 Aug 2023 15:47:55 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeggddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnhepkedvlefghfehtdekudeggfethfegleetkeffveefgefgiefgkeefleet ueejkeetnecuffhomhgrihhnpegvnhhtrhihqdgtohhmmhhonhdrshgsnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhguodhmvghsmhht phgruhhthhhpvghrshhonhgrlhhithihqdduvdekhedujedtvdegqddvkeejtddtvdeige dqrghrnhgupeepkhgvrhhnvghlrdhorhhgsegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 213DEB60089; Wed, 9 Aug 2023 15:47:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440 Mime-Version: 1.0 Message-Id: In-Reply-To: <20230804071045.never.134-kees@kernel.org> References: <20230804071045.never.134-kees@kernel.org> Date: Wed, 09 Aug 2023 21:47:24 +0200 From: "Arnd Bergmann" To: "Kees Cook" , "Russell King" Cc: "Lecopzer Chen" , "Oleg Nesterov" , linux-arm-kernel@lists.infradead.org, "Linus Walleij" , "Russell King" , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] ARM: ptrace: Restore syscall skipping and restart while tracing X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230809_124758_288408_52ACB0D7 X-CRM114-Status: GOOD ( 22.17 ) 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 4, 2023, at 09:10, Kees Cook wrote: > Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store > thread_info->abi_syscall"), the seccomp selftests "syscall_errno", > "syscall_faked", and "syscall_restart" have been broken. This was > related to two issues: While it looks like my patch introduced both problems, it might be better to split your fix into two bits. > - seccomp and PTRACE depend on using the special value of "-1" for > skipping syscalls. This value wasn't working because it was getting > masked by __NR_SYSCALL_MASK in both PTRACE_SET_SYSCALL and > get_syscall_nr(). > Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(), > leaving it exposed when present, allowing tracers to skip syscalls > again. This part looks good to me, at least it seems to be one of multiple ways of doing this, depending on how we want to encode the syscall skipping in the variable. > - the syscall entry label "local_restart" is used for resuming syscalls > interrupted by signals, but the updated syscall number (in scno) was > not being stored in current_thread_info()->abi_syscall, causing traced > syscall restarting to fail. > > Move the AEABI-only assignment of current_thread_info()->abi_syscall > after the "local_restart" label to allow tracers to survive syscall > restarting. I'm not following exactly what you are doing here yet, but I suspect this part is wrong: > diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S > index bcc4c9ec3aa4..08bd624e4c6f 100644 > --- a/arch/arm/kernel/entry-common.S > +++ b/arch/arm/kernel/entry-common.S > @@ -246,8 +246,6 @@ ENTRY(vector_swi) > bic scno, scno, #0xff000000 @ mask off SWI op-code > str scno, [tsk, #TI_ABI_SYSCALL] > eor scno, scno, #__NR_SYSCALL_BASE @ check OS number > -#else > - str scno, [tsk, #TI_ABI_SYSCALL] > #endif > /* > * Reload the registers that may have been corrupted on entry to > @@ -256,6 +254,9 @@ ENTRY(vector_swi) > TRACE( ldmia sp, {r0 - r3} ) > > local_restart: > +#if defined(CONFIG_AEABI) && !defined(CONFIG_OABI_COMPAT) > + str scno, [tsk, #TI_ABI_SYSCALL] @ store scno for syscall restart > +#endif > ldr r10, [tsk, #TI_FLAGS] @ check for syscall tracing > stmdb sp!, {r4, r5} @ push fifth and sixth args > If the local_restart code has to store the syscall number for an EABI-only kernel, wouldn't it have to also do this for a kernel with OABI-only or OABI_COMPAT support? Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel