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 D1CC8C0015E for ; Thu, 3 Aug 2023 23:17:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32E192802A1; Thu, 3 Aug 2023 19:17:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DD8528022C; Thu, 3 Aug 2023 19:17:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A58A2802A1; Thu, 3 Aug 2023 19:17:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0C82728022C for ; Thu, 3 Aug 2023 19:17:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C9F9CB2F60 for ; Thu, 3 Aug 2023 23:17:29 +0000 (UTC) X-FDA: 81084357018.13.7FFE348 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf30.hostedemail.com (Postfix) with ESMTP id DC4B680016 for ; Thu, 3 Aug 2023 23:17:27 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=M3JW4qbz; spf=pass (imf30.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.174 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691104648; a=rsa-sha256; cv=none; b=8LBzI/dzKiYr+gVvibRLXyLci7Xk5WZqP+JlLlq/ajA2XGroVnMktr6CdFvrLIosq6TGlq a5X195dfMFC3NPg9y7BLBs2p5GepyhYzVcicz1OPrDXMQJlqidxrduKjjx4LnkIYyesB8t CTPovzQcpKTNJKK5jbCNiQRjHLQRkPw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=M3JW4qbz; spf=pass (imf30.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.174 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691104647; 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=uAX8/BAoKRR9bpEyT2pUxkYfnwIbAbYh0zgu7kZ+rdo=; b=mgWVk6dPsEVdbyMqbHRQZpTJTRGiwEZc61jMSsLOeeInVQIJ3Hb30WmMaEF6wYJah1uI+u Nj7Xe0qKLH6XO6OIxchGiS9K6Q/DF6ACxkPsocHkW7NSEe1kNDE3z2SkEXPmLe8//FRYvi OiHDGJdJ2+NISAYeGosQ5TQ+9Z9LIsw= Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-686b9920362so1081668b3a.1 for ; Thu, 03 Aug 2023 16:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1691104646; x=1691709446; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uAX8/BAoKRR9bpEyT2pUxkYfnwIbAbYh0zgu7kZ+rdo=; b=M3JW4qbzHMtiBaVV+XfFBn1fsvKda9lPpptkVIw8hZm/FUU95/wvAXWV+n7Bo0xrSN XpQeyyNevHkjeS8VMIGwQK+EdGDhSk/5ZTxmG6HHRdjV3/sPQ5JPcl3IQlrdDxc145c7 ZTaNF/CEIIPTHkwJu1goZt4kjifTLnNJR9x+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691104646; x=1691709446; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uAX8/BAoKRR9bpEyT2pUxkYfnwIbAbYh0zgu7kZ+rdo=; b=Pfsw600nJUa2zqlyjSrGLyE49urD1Hz4Cg5o4FtQmM2ZZDxmC0dEKgAm2EsFBGOqeN wbH/S3xIfo16WOMYuoaEj1OMzQdlGONL8UqBnCvCgSEftQTrSDKH6WzC9RGvOWroBhJe Auvm5BABAyyKzn1NM3ptlXstfFcrAqTHOC1o0RDRp5BlvjDN7fO+PhfsNODB4aSTpqNL 3FcNP/bp3hn+9+uSpxwzdBph8Xwf58EgXkdBNC7Ene5yWKmvKJyyCiqj2wdkiwQQcDGk hKuh1YyNlikmDFKoCGoNdOdTJEA/I3005rTDxQSrKY59YAapHLn9b3TFzQejtw+vbhQL qd1Q== X-Gm-Message-State: AOJu0YxVbOzsHTA0+VWR7aGRrfuQGuDcRiaEN2+Ps1Wm2jliU55S7isE efZqBldxSi1bitbC0U2lj/j3ww== X-Google-Smtp-Source: AGHT+IEj4C/z2qsGxkJgyRwpjg3NqlxZEdhHZ0f66XagZ0cXhYhmwUvu1RZI32U+pelJi/n6ndb3KA== X-Received: by 2002:a05:6a00:150d:b0:686:254c:9d4e with SMTP id q13-20020a056a00150d00b00686254c9d4emr108098pfu.14.1691104646559; Thu, 03 Aug 2023 16:17:26 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id u19-20020a62ed13000000b00653fe2d527esm360174pfh.32.2023.08.03.16.17.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Aug 2023 16:17:25 -0700 (PDT) Date: Thu, 3 Aug 2023 16:17:24 -0700 From: Kees Cook To: Arnd Bergmann , Lecopzer Chen Cc: Russell King , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, 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 Message-ID: <202308031551.034F346@keescook> References: <20210726141141.2839385-1-arnd@kernel.org> <20210726141141.2839385-5-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210726141141.2839385-5-arnd@kernel.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DC4B680016 X-Stat-Signature: cegati37smoypr47khgaaqgszn4yst6t X-Rspam-User: X-HE-Tag: 1691104647-903568 X-HE-Meta: U2FsdGVkX1+ZHfPmReiVilBF6Pv3eULp48+uaCZw2OFZLWRr3Rxz07afCGXc4f4rzO0xvSCIaXfR/vNHzt+Va4lE+j1EOLVOCLWbXPt5lTGWHhK5B2DuhJmE3i+ybO34CdzqS1K1k8dHLvBGrtl7Czv2ivaaiBjllatAR2TK9iSatc0LRHWRE/sNO7j11mwHFJEY2Ov1nEG04GTA1cG3tPBABLkjP1tAWeSYW+mVRioHGSAj2BEFEsZADhmnylYlGD1GI6Z52YMy4qSJZhO3kVXxHLkmoveC0I/6XCrb8Buub12lG37aPkSLhZ+x+tF1cUK10QUsFOuogrOz2RbBB8UOufSzI8ArhktBhSxypo+vBsvHOgvo3ITg2NWVpJHh6ZxlrwMSqB9IOwtxGXjk6KOEKBpMzXCEcpaTALq+qQKHpWm9RJgtEbyQNR0p6aByg1hYbBhuKTV3CqWc03z/P2bdXNEDxD44vQDFR6gJzU2Cnwph/wsBqLgnqTiedkXcKREa2ld6S/l7cOL8Vhe7pENAO6NbkFPwnvfqRq/smVUz6pitoTlQfhrgxmotFXKHJfDRqXpGpAiFP+Q8mY86NVf62qEPthee6UbkhyNqbXcGXQnNHaR3avdnTVwub9of1HcRYZGekdtLUcE8dDq9aERVcj99zjJq+BH0Fg+e2p24UOqfpuiHAcwV0OlIDW8ilQiwW1m1Qk1xkMLkIbqzInl6LD+OPqHkD2FytVNS/cGgOxg2uY7SXLE5v2sy7bcB9nlUbNs9MovFAO92+QY6aV6894sJtPQtReftz+Fztns2ofdeiRcBcX33C+6yxLmif3XWk/0VbVs91lODcgHS+qDgunNKn4bZYgPB6cxDKH+flh9KiGKYw+S6MmmOxzFVoRT8/3SUfuFF9w3hKJ4ywWwFe9PL5XBC/xCxW4e2+zk82sKFB40sBTDvQTs+Vtzh8jeNWGu0YTKOVaCRW0E lN+bdhpZ BvEC6/hm6Nm6Lp3eCmA5+QM1obNRSyOS/lqedMBpdUCIEQ8oE6XtnvYmcZ+254SVDOptDUBF6UaIKhmwJvBXnhY/rCHLBH4bO30Ndzp2NexpgcEt9Ruv5RlQ/v4bDbQGpqW9Pg5p7iIdZ94nfO0J2iAjega/ocmXN7uxVIqEFDuos6RBTkGIIu4/GBuMelsUcDtFIdYJeudiDJRU+MV4R5Tm/XaBh1zp0/Sh7JB580Smcg73zCrPu3yH7cWzwjsXroWustTgwFFmmt4GnehXgs2h3H749xA8f4L9xr1z3/kw5b0/ouxoSeDcJ03YmzNxcL2UiTjAF4EpPW302sjhWeZtIOLAHm5YDxB4V+n2IAs0VftwyA7WLt4d9aXFD430vW9QIrH6MqGriVvWNVk34LbPfFKjMWDJaJCvKzOpW4288lcvDrKV+/Pn7q6oKbRFoqCYOEO/K5b9WnjSD5xG8XiVcCl0/VUfk+20V+sH9VDKoOENngiVyY8MnrxLKwsDuWQOaoGjee1LqN/8BJ2Ef4HdlDIp1nrGGk+QQVKQw5X8/YYzl/HMVInzIv2hUxcFSupk2SpCIB3FuSKU= 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 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. > 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. > 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. Anyway, I'll keep debugging this, but figured I'd mention it in case anyone else had been seeing issues in here. -Kees -- Kees Cook