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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44B01C41513 for ; Wed, 9 Aug 2023 19:43:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89E6C6B0071; Wed, 9 Aug 2023 15:43:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84E5A6B0074; Wed, 9 Aug 2023 15:43:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EEED8E0001; Wed, 9 Aug 2023 15:43:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 611536B0071 for ; Wed, 9 Aug 2023 15:43:08 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1EB8B120FC2 for ; Wed, 9 Aug 2023 19:43:08 +0000 (UTC) X-FDA: 81105589656.11.898F16E Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by imf24.hostedemail.com (Postfix) with ESMTP id 0373418000B for ; Wed, 9 Aug 2023 19:43:05 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=p7liFpTR; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=m5Yc5lz4; dmarc=none; spf=pass (imf24.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691610186; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YEcqCFxUYGUWqz2IlUXTkb/oxp7H5kGX1NNGYfEDwAs=; b=WVJykyrDL1P/6kt2Fc6RM9Phg/Imxl5aUWcFXGOIk8WAzIumy441YTmTNztivyK/IKQxyT WWo2U7YqqAhMq6tS8aWmM02D5SLLYGerstmAI/ZoluZLF5IrRgnEKiwjm/OI5ndS2/bCUx 5LB0+ChENMgcpo5BU8TqGiOGg+aGPks= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=p7liFpTR; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=m5Yc5lz4; dmarc=none; spf=pass (imf24.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691610186; a=rsa-sha256; cv=none; b=gBDRNjkhg5SBPImjnlQ6+oyaYrK0EZWOqnOAiEqVc1NhspwpBkAr9W4lo7r07naGwlZsTP ScQ3P0XJh69tmV06xxMTsklXR0BdwEpqJf+m4JM/Qkdujef7P4K9I7cFkV6TNKvKwf9S/i GJ3ORZL6uEq3msWbyedneuoAq2+xFLE= Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 087FA5C0162; Wed, 9 Aug 2023 15:43:05 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 09 Aug 2023 15:43:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1691610185; x=1691696585; bh=YE cqCFxUYGUWqz2IlUXTkb/oxp7H5kGX1NNGYfEDwAs=; b=p7liFpTRJPzvF2BL27 OlPSzhK21VYRzNUOB0VVBTrnKUZhBazHP52H57yOOQd/W+3FdD3JS8bIHuxsDWbg CF+L1lkaHCEORvwW5LUnEGWXoymXM4OMPCHjKrZS6wuOMHibomIrRWgzzXEv2Wzm krVJVAEnL1SERZgeBJDXMmu+otenrkvdee8s1Rb+lBxS3CGsrQS0VOdHD7htb6gZ Iq1azx08g+Y/lLywwt5xD4fiDxkT5fCXjparzlXkWhx5zLUOSoKrymZ62e+N8Eer tu17nWp7GGnTdz0r9SoL0Cpa54frxDLqGIFZM+iOro9t1eZ6H4y2jwgqG9iq80em pAHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691610185; x=1691696585; bh=YEcqCFxUYGUWq z2IlUXTkb/oxp7H5kGX1NNGYfEDwAs=; b=m5Yc5lz4i6fwIMRmI5ZnP6GYL5Ysn LkcO8LVeq+K96zVRDH493c0uZ7bKbWFhfU4yfpqashCrSJ3L33sYjdek6MVtI729 obyxAiqu6kd5DLMs4JIlJC2LCSSNLSZUPJ8aRnIWduzIMZ0Yo6vFs2cKpDcmjJcb 2ow4fZPidM0mUXH8LjN1pPv02dXAL+Y22J7TdolASeDD1Q//Hgj71qE3fuNGf5yi MmDbzy2MZkVvARtlq8psjR96yxoOEEb+lRyAvFxgHB/zS4a6wt4ZhUAOkCMA/Plw vsYGxh3NjNpirAIdfxrEdafzZ0HKjw+fASOY+USpGoLJUD4lwl5MV/xew== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeggddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepkeelfeefvddtkeffudegffffjeffjeeugefftddtteevffdvueetgfejjeel tdfhnecuffhomhgrihhnpehkvghrnhgvlhgtihdrohhrghdpkhgvrhhnvghlrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhgu segrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C093B6008D; Wed, 9 Aug 2023 15:43:04 -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: <202308031551.034F346@keescook> References: <20210726141141.2839385-1-arnd@kernel.org> <20210726141141.2839385-5-arnd@kernel.org> <202308031551.034F346@keescook> Date: Wed, 09 Aug 2023 21:42:43 +0200 From: "Arnd Bergmann" To: "Kees Cook" , "Arnd Bergmann" , "Lecopzer Chen" Cc: "Russell King" , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linux-Arch , linux-mm@kvack.org, "Alexander Viro" , "Linus Walleij" , yj.chiang@mediatek.com, linux-hardening@vger.kernel.org Subject: Re: [PATCH v5 04/10] ARM: syscall: always store thread_info->abi_syscall Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0373418000B X-Stat-Signature: pqu5d9xcmbiy4ohnu8k53crh59dwygne X-HE-Tag: 1691610185-617745 X-HE-Meta: U2FsdGVkX1+8rzSVFwpl8NibW0kfuJBHM2K3GQYL2tcNevhxN3uy9keJGJPeubMfpz0Dt71m+fAxcUqbzMHDiA3K0L9ow6kfyt+xl6gIee4HMOEz3D7Ezz/oL6SFxlIv7IPKrk9xkYm1CdHWeofHJ94LiIrD4oq3ZVr7y0+p4O76kNbfKq61+O/oYLQC9zUthh1Ml0A2hXWuy3mEdfnC3Ch2BfdILmMSUjNPmkC8ZUjEArVB6g7a+8nY/tmEuIeHiJI1B+13IVjaQfQ8S9HNv15LeJphBRerCsDndCrkSCZ43iafU9CpqDwVLHlNgTlV49KWKOsoVZ7P1w3tNt6kLZerdSqeQye2bQYeyrrklEhO7mnuK85GZmJhMuYpoatkPxJIE6Jf1TrrlUh32gSG4Dox8G8ByxMdUIbDnq41lG87lSsbtv7WOd/IXftD1qhbYFU2IdQhRrHfbjnteHN8qCaZIgPxN9/gptMHOWF/Cr7sVOSKfHsCeQZWlPHVqWmy5Almv24kSysAaUvk37u2EuMCSFbFehIyECa6j/cBAlLmkSKewWLmTB3uOWEPUFoqoXLim2HiqnKu0ucYmC6QGdSlSry+hRnOYV3YdGIpiHxMx3VXdxGTLkjvLphFdDjytdmE3pSJz8QG5nGsGEbVmynu/Mhe6DkxnrqkaM6+vFtHMg0drwAalAfMWeQCG5zRvvH3sFVQskISrn96jIGTE3FY7C80RFOQFCJidBGAh4PuBMFEBOSyE4k98mPg1onHaa09vZW07zCZzKsRLJjcFY6mzPQPOaEMXJOEBj8F07z77KdVJFfKwM2BwWrsFBJIajUKZOP8zDqa56jTlYy5Jhk09yO87Mp39BmN21vTdKJ9sZ7HfbXZIOadWmP6rq1csg3urXvOhWxzTxDgd5lN6DOKVMz6Wo1W+s5sBHhJsU/yKct0yblO7WXszLDjhBSuDEHOCIdvsFe/JVxLXbo BPfZLEWz va+O41wg+8GxrMkALHxIN//KZgZdCa3KXet/NnPp0Kg+fAeFYZms5nzJ67OZnD/Wy93vBrFfVJDaipj9u/WSGv07MMXUL/vP+/GYDXYYMW3qloxKywJAxOfQWhVps50JaVSWFD69gzeRht+pizv27Dn1wBMNegywFod7P18vZxH9U9Dc3sqDssfrGe8LIKp8chxohftDIDmK0o5iKt1UsQKRa5KAW/a8e53IYQQ94ylSVRRZJlbkiUgHwasLBZ2WKE3pje/qOVg2i5DOB4bxNxOjEetr19R8f2aQG4NjRitwvkJV0ogVWnTmRFLCYQZlNNpjbF/psi/W2OeqhE8vGEVSIngvQbXTqhjBo6kOtaxj6EYI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 4, 2023, at 01:17, Kees Cook wrote: > On Mon, Jul 26, 2021 at 04:11:35PM +0200, Arnd Bergmann wrote: >> From: Arnd Bergmann >> >> The system call number is used in a a couple of places, in particular >> ptrace, seccomp and /proc//syscall. > > *thread necromancy* > > Hi! > > So, it seems like the seccomp selftests broke in a few places due to > this change (back in v5.15). I really thought kernelci.org was running > the seccomp tests, but it seems like the coverage is spotty. > > Specifically, the syscall_restart selftest fails, as well as syscall_errno > and syscall_faked (both via seccomp and PTRACE), starting with this patch. Thanks for tracking this down! >> The last one apparently never worked reliably on ARM for tasks that are >> not currently getting traced. >> >> Storing the syscall number in the normal entry path makes it work, >> as well as allowing us to see if the current system call is for OABI >> compat mode, which is the next thing I want to hook into. >> >> Since the thread_info->syscall field is not just the number any more, it >> is now renamed to abi_syscall. In kernels that enable both OABI and EABI, >> the upper bits of this field encode 0x900000 (__NR_OABI_SYSCALL_BASE) >> for OABI tasks, while normal EABI tasks do not set the upper bits. This >> makes it possible to implement the in_oabi_syscall() helper later. >> >> All other users of thread_info->syscall go through the syscall_get_nr() >> helper, which in turn filters out the ABI bits. > > While I've reproducing the bisect done by mediatek, I'm still poking > around in here to figure out what's gone wrong. There was a recent patch > to fix this, but it looks like it's not complete: > https://lore.kernel.org/all/20230724121655.7894-1-lecopzer.chen@mediatek.com/ > > With the above applied, syscall_errno and syscall_faked start working > again, but not the syscall_restart test. Right, I also see you addressed this better in your follow-up patch, I'll comment there. >> Note that the ABI information is lost with PTRACE_SET_SYSCALL, so one >> cannot set the internal number to a particular version, but this was >> already the case. We could change it to let gdb encode the ABI type along >> with the syscall in a CONFIG_OABI_COMPAT-enabled kernel, but that itself >> would be a (backwards-compatible) ABI change, so I don't do it here. >> >> Signed-off-by: Arnd Bergmann > > Another issue of note, which may just be "by design" for arm32, is that > an invalid syscall (or, at least, a negative syscall) results in SIGILL, > rather than a errno=ENOSYS failure. This seems to have been true at least > as far back as v5.8 (where this was cleaned up for at least arm64 and > s390). There was a seccomp test added for it in v5.9, but it has been > failing for arm32 since then. :( > > I mention this because the behavior of the syscall_restart test looks > like an invalid syscall: on restart a SIGILL is caught instead of the > syscall correctly continuing. The odd arm behavior came up on IRC recently, and I saw that this was what arm has always done, but I could not figure out why this is done. I tried to see where s390 and arm64 changed the behavior but can't find it. Do you have the commit IDs? Arnd