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 3E62BC0015E for ; Thu, 3 Aug 2023 23:17:57 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VqggyNLR85oTMYRw7wdev1wo4mk2QWR1zPaO9OC+e3g=; b=IYta2dBh+znMAR wgCO1RPGVagvdf4/6mh3lV2taicjpvz8xsd1E0ZQ8TN8zWffymVylp9+9PZOjJLjYdO08ogF04iPQ WSubbTrgnY1CIMaIqZXRYxkvDnzavfT+n5JQNo5PK7ZWRCFrMTSpXirrHJPRYVzcCqHgDzV8WDY9i hPuDCd9Rma2NR1SLQirAN/5zIc11/ZN/Bxl2jg+LKk0sT1guLy9bWuh53raAUxVBbp2x1imP5uKSM /uXJVoN+rRH+aj38tDyNZf9hpeLm9gzHZ/j3zua9byXSuJJddFurVYXjKR/mGtkD1eELg2F2T6Aam UZBiCj8IZC3oknnsWd9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRhZU-00B4bS-2I; Thu, 03 Aug 2023 23:17:32 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qRhZR-00B4am-2p for linux-arm-kernel@lists.infradead.org; Thu, 03 Aug 2023 23:17:31 +0000 Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-686c06b806cso1077100b3a.2 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=cCSfr2aR95lHTNrgN0IRaD8mnmxLgWKrQUPIl0WGSpVC7McvkmKqmVVpKswZoXSPi0 M70+cKw6FfSdz8+j//pMX15PtrFLVE8a5xPWsm+Kza+aiM27NJ+WgdLE4eFBucCnZ8IQ cOBHQdZKisuFF6OHKlajqVOYxS6dFCBS05K8Q515Kih+6Mtm9P/719AJUBASs0URUton 1YIfAI8zIfYVFLXcP44odl+I7ucdNJSizeP4n2zx5oEeg8tWLD8dYqyUP3vYwKgGpe/y lsVGOrsPv3JnlpU58gcwMZsz+UrQXAofDKN7VJfyYbGUxOq+X7SuDqrUIVG3jPpMquZ5 dglA== X-Gm-Message-State: AOJu0YzzLl6mxCu1Xx8DPICEtDJF1QhOlcaJeoFYlcj/KnJfEvAFvgbd oefONhCbUYvHcYBP6FWP/C3vnw== 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-Disposition: inline In-Reply-To: <20210726141141.2839385-5-arnd@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230803_161729_936530_925AEB58 X-CRM114-Status: GOOD ( 31.01 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel