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 3430EC001E0 for ; Wed, 9 Aug 2023 19:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbjHITnK (ORCPT ); Wed, 9 Aug 2023 15:43:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbjHITnJ (ORCPT ); Wed, 9 Aug 2023 15:43:09 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2747E10DA; Wed, 9 Aug 2023 12:43:08 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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