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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FD73C433E7 for ; Wed, 14 Oct 2020 18:01:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 762A921D81 for ; Wed, 14 Oct 2020 18:01:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BKP0J9UK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 762A921D81 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=kNnOb8tMWvBmltRl4hNtD4OJucDyU8xxcO/laG6Vtq0=; b=BKP0J9UKUQhFN7eLdJeew0lrS 2gLBeeSGERaArgMX5oZUxfLUK+OCV3JaaYPkTu1Vu86DweqZc1QaJJ4r9vP5TTvFGSm8Ct+PRLsba ztGPXY5qUB3WWJkNbYZK3KzxaSgjiOIFiASLNRkpM1WPpZbJYtSrAMm+SwXQCiZ73IhLoK8OmfxOT EOHkiWXoUEBiRlyIn9mpMj5qVW8PH4ZR0KfENWb0T0O/aiiLm94eeNriXHMAxV2+X4JrvEujXK2S4 /xDu2x5+v/c5AThbTOGh6FlvgHeNsf+84U+JSXu4bLdxHqty+U4UlTuD6LYxthWTjA3aJ8c8KV9oD Xryd4ZbmA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSl4a-0002Uv-J5; Wed, 14 Oct 2020 18:00:24 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSl4X-0002UX-Ha for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 18:00:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F481D6E; Wed, 14 Oct 2020 11:00:17 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A7CC53F719; Wed, 14 Oct 2020 11:00:16 -0700 (PDT) Date: Wed, 14 Oct 2020 19:00:13 +0100 From: Dave Martin To: Peter Collingbourne Subject: Re: [PATCH] arm64: reject prctl(PR_PAC_RESET_KEYS) on compat tasks Message-ID: <20201014180013.GM32292@arm.com> References: <20201014052430.11630-1-pcc@google.com> <20201014095356.GK32292@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201014_140021_689387_4BAB9D5B X-CRM114-Status: GOOD ( 37.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Vincenzo Frascino , Will Deacon , Kristina Martsenko , Linux ARM 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 Wed, Oct 14, 2020 at 10:45:48AM -0700, Peter Collingbourne wrote: > On Wed, Oct 14, 2020 at 2:54 AM Dave Martin wrote: > > > > On Wed, Oct 14, 2020 at 06:24:30AM +0100, Peter Collingbourne wrote: > > > It doesn't make sense to issue prctl(PR_PAC_RESET_KEYS) on a > > > compat task because the 32-bit instruction set does not offer PAuth > > > instructions. For consistency with other 64-bit only prctls such as > > > {SET,GET}_TAGGED_ADDR_CTRL, reject the prctl on compat tasks. > > > > > > Although this is a userspace-visible change, maybe it isn't too late > > > to make this change given that the hardware isn't available yet and > > > it's very unlikely that anyone has 32-bit software that actually > > > depends on this succeeding. > > > > > > Link: https://linux-review.googlesource.com/id/Ie885a1ff84ab498cc9f62d6451e9f2cfd4b1d06a > > > Signed-off-by: Peter Collingbourne > > > > This does seem an anomaly, but it's not an isolated case. I suspect > > that some other prctls are also missing a compat check -- PR_SVE_SET_VL > > doesn't have it, for example. > > > > So, I'm not sure it's worth fixing this one case in isolation. Fixing > > all affected cases may have greater risk, and it won't stay fixed, since > > the compat check will likely often get forgotten when a new prctl is > > added. > > The only other affected cases involve SVE and that doesn't have > hardware available yet either, right? I'm going by the binutils CPU > list, which is the closest thing that I'm aware of to an official list > of all microarchitectures and their supported ISA features: > > https://github.com/bminor/binutils-gdb/blob/6248f5e4fc4ad1e433156520e44ac3217c39a621/gas/config/tc-aarch64.c#L8888 > > (and I know that Neoverse V1/N2 isn't available yet) Yes, that's probably a reasonable list. SVE is supported by Fujitsu's A64FX part, but that's in few pockets. In any case, it doesn't feel legitimate for a compat process to be using this. The chance of extra compat checks there breaking something seems pretty low. It's not like we ever promised it would work on compat. > > So, is this anomaly in any way harmful? > > Not as far as I can tell, at least for this specific prctl. Ack > > Can the code be refactored in such a way as to make it hard to forget > > the check in future? > > I've never been a fan of the arch-specific prctls being listed in > kernel/sys.c. It seems better to me to have that handling be moved > into a new arch hook and that should let us remove some boilerplate as > well. We can make the default case in the prctl syscall handler look > like this: > > default: > return arch_handle_prctrl(option, arg2, arg3, arg4, arg5); > > And move the arch-specific prctls into a switch in > arch_handle_prctl(). Now, since (as far as I can tell) all of the > arm64-specific prctls do not make sense on compat tasks, we can add > an: > > if (is_compat_task()) > return -EINVAL; > > to the top of arch_handle_prctl() and any new arm64-specific prctls > will get the compat check by default. Of course, if we add a new > compat-compatible prctl in the future, we may add it to a new switch > before the if statement. > > Peter Something like that could work. I did have a try at cleaning some of this up some time ago [1], but other stuff happened and I never finished it -- not sure how relevant it still is, but might be worth a look. Cheers ---Dave [1] [RFC PATCH 00/11] prctl: Modernise wiring for optional prctl() calls https://lore.kernel.org/lkml/1526318067-4964-1-git-send-email-Dave.Martin@arm.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel