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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 EA9B6C4338F for ; Mon, 9 Aug 2021 10:54:36 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id ACD31610CB for ; Mon, 9 Aug 2021 10:54:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ACD31610CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=BUtldS9tX/dmt9ixLsbj06CE/14R3VNFFAzn4EeQ4OM=; b=mKMu6HqrQS1DhE xR2ne/aZ8YDc47ZDtKY2+8vCnZSoBE8qFnAjpNzql4/z757dRrcHw4g4f6rthIJT5L2z08hOWYKnK 0yuDolpkkxfFiLZ1Tx8nLy5PB2wcxVQKxfRcvZfYK+9AnOHHT3m/3+vTWWH1adJyw4UBOUhqXKm6V MlGDwOyS29eqZnUU7E2RTRLDez+aPnw5freEP3rk6BfVRAwLg+tYpSm8+ijKZe5frVcfC9EHx+llU QdmAGtWly1UGofdNy6QYrsHC2P2xp/wD/Nw9QMVQRhNEdpzSsN2ni+6qIrI0SBAdN1VGc8iwShoPP qQ25QcU35jDSwHmIws0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD2tj-000FZT-Dr; Mon, 09 Aug 2021 10:52:47 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD2tf-000FYn-UP for linux-arm-kernel@lists.infradead.org; Mon, 09 Aug 2021 10:52:45 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id EC1716023D; Mon, 9 Aug 2021 10:52:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628506363; bh=eC5/ptDREwdD+Mi5IQ60r27+kT5wy5bRZnE+psxz7s0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VBkRRgmLfRcjEB2tTXpETlkjSBkuUoq2zHM7UIdOyaRqtqwwPGzQfEwK0LktKgT1L GadNmtMDJ/YSSalSVnfX9n/F4ZUBDctKpAdg6W4hMwpn8LFcxvZnVxYqPaScFxdyMB 57wFPZXwQhRvgg33G0lCN6ztK02ryRPOPchikZn4TIXuVpNH8SquSVfmqfr028gQUy 4Sqy9MCam8FLRxlz5rbzXORFscm8HQ9gklK1jw1PxLFOwR1OzpP5J4hCMGjqZgvvkQ rP7k2REVJ33TIZa3HVkb7wdxdRo1aamgLKSe0NVrUWR+3Splygt16YYElZB6ndkU2S 2hSxXCn4TYsvw== Date: Mon, 9 Aug 2021 11:52:38 +0100 From: Will Deacon To: Linus Torvalds Cc: Catalin Marinas , Linux ARM , Linux Kernel Mailing List , Android Kernel Team , mark.rutland@arm.com Subject: Re: [GIT PULL] arm64 fixes for -rc5 Message-ID: <20210809105238.GA5693@willie-the-truck> References: <20210806135331.GA2951@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210809_035244_062797_0F07821E X-CRM114-Status: GOOD ( 22.17 ) 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 Hi Linus, [+Mark] On Fri, Aug 06, 2021 at 11:40:33AM -0700, Linus Torvalds wrote: > On Fri, Aug 6, 2021 at 6:53 AM Will Deacon wrote: > > > > Please pull these arm64 fixes for -rc5. It's all pretty minor but the > > main fix is sorting out how we deal with return values from 32-bit system > > calls as audit expects error codes to be sign-extended to 64 bits > > I've pulled this, but that change looks _really_ odd. Cheers, and yes it does. We're stuck in the middle of the architecture, the compat ABI and internal kernel expectations. More below. > First you seem to intentionally *zero-extend* the error value when you > actually set it in pt_regs, and then you sign-extend them when reading > them. > > So the rules seem entirely arbitrary: oen place says "upper 32 bits > need to be clear" and another place says "upper 32 bits need to be > sign-extended". > > Why this insanity? Why not make the rule be that the upper 32 bits are > always just sign-extended? There are a few things which collide here: The architecture doesn't guarantee that the upper 32-bits of a 64-bit general purpose register are preserved across an exception return to a 32-bit task. They _might_ be left intact, but it's up to the CPU whether you get the value you wrote or all zeroes if you read those bits after taking an exception back to 64-bit state. Consequently, we can't expose 64-bit registers for 32-bit tasks via ptrace() as the resulting behaviour is going to vary based on how the hardware feels. Maybe we could sign-extend everything on exception entry, but that would necessitate many more syscall wrappers for compat tasks than we currently have so we could truncate pointer arguments back down to 32 bits. Instead, we currently handle this by (a) treating the registers of a 32-bit task as 32 bits (hence the zero extension when writing the value in syscall_set_return_value()) and (b) explicitly clearing the upper bits of x0 on exception entry from a 32-bit task in case we previously leaked a negative syscall return value in there. The problem then is that some in-kernel users (e.g. audit and some parts of ptrace which abstract the syscall return value away from the register state) _do_ want to see sign-extended syscall return arguments in order to match against error codes (see is_syscall_success()). So we end up in a situation where we need to sign-extend the return value for those, whilst leaving the zero-extended version in the actual pt_regs structure. It's ugly and subtle because the sky doesn't tend to fall in if you get it wrong. As you can see, we're still fixing it. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel