From patchwork Sat Jan 7 00:59:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Viro X-Patchwork-Id: 40289 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1104900wrt; Fri, 6 Jan 2023 17:05:56 -0800 (PST) X-Google-Smtp-Source: AMrXdXtkwgFqkvOL/MPtUGIZEWIphOBAsGbEKIGQk+SKfC2gpEMao/Eq6dG3ZYhorD4/IBuQ5oUs X-Received: by 2002:a17:903:1091:b0:192:4904:afae with SMTP id u17-20020a170903109100b001924904afaemr46932273pld.24.1673053556053; Fri, 06 Jan 2023 17:05:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673053556; cv=none; d=google.com; s=arc-20160816; b=raI690L2/OsFc+UogU5qzpxSMrBTOlyZ6/zMeqnwFK2qq0ygQtSwEse3KrAM6/GcOc xJWvJYSpysTIE0rWiDF5APlcm5VQibfh42EQwZAEgDOWctNPpTLopA0GZ5y9SXM9GcXc iKhQZozDPV51zBr+Unxg7iUyzNDWrWOBHFEUzxvXUk4ab6amvm2neju8xCDLEcMRQJzy 1zORzkrgfg1Y6HhmqsArsDlB+TDq+dnbY5Mhw+KUp+9uYFIaIynrwDt7OUKMg2629m77 lI1ezs6x0KTqp6Nij705naJZzYmrWTqXEFmOAWTru7DLjC6+Ts+AZFcVDT7TpvwaoORp CjiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=AqW0MiKJDzcQWypSmFaeIye4cnxqlSKPzLx3ofGTx1w=; b=zK0OiSqhuoHX6LD4hTQWHpQ0/UBvPfuxMN2AR3ydjL/5gWyC19oi9dSXz12pYmyEYt pwq7GXzeNycs7zz8nSsfOk/Q0xv+4Y7sOWjdsUmUlAGncyeGXDyHT6HYnjm8ZWtg0jDN S+T2FlLVo/wifQr2ugY1nEanRPNrcT1R9KvoA6Ck8kY1DLD68F+cpOwyFvmxxDhNih5l O+QsRNMDKw9ZTEozOP30VHThOLDVojVsXFLt1BahLta9hHq0pPclNhMpF/oqJ1DQ/aeq 11XYfTiYIgoBIvgWMzoRBPjftpCgxH1c04uvt3fSHvWSz//ttGyka5Dhwfm3ekpQJ5br 0wcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=C1duj2Fb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y4-20020a170902ed4400b00178170100fasi2293263plb.337.2023.01.06.17.05.43; Fri, 06 Jan 2023 17:05:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=C1duj2Fb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236698AbjAGA7u (ORCPT + 99 others); Fri, 6 Jan 2023 19:59:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236934AbjAGA7l (ORCPT ); Fri, 6 Jan 2023 19:59:41 -0500 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B631848C0; Fri, 6 Jan 2023 16:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To:References; bh=AqW0MiKJDzcQWypSmFaeIye4cnxqlSKPzLx3ofGTx1w=; b=C1duj2FbsZAbWXnupQD72vTpZ/ wDd3t7wflYdtqDTy7YnbpcCNF8ykFROaXmgvAR2QMZhIP/tLxkS8pu03jyvS4nlTxiWh5KMBuppCl viKycqV7kINE0ca9pmP1GJof52pCrWtkZvGKKI/bGyhluWPHGa//VWWI8jHk/rvpZWNcRD9+AxaRo OPISI+/MX+VMwTkuqzzqvkN83ufR4/lJuj0B5EBy0OZvu1wsL3KBC6+vOFuK3Lv8Fbk1swMxzKm2j QN3oMx/s6R7AWs8pFlrW411PLNmimqt6LOVUQB96a2UyV2uV4v4QLzuzIBKFnI3yS7QIKzqz7i7mv 0hOAuNIA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1pDxYX-000FvY-2Z; Sat, 07 Jan 2023 00:59:29 +0000 Date: Sat, 7 Jan 2023 00:59:29 +0000 From: Al Viro To: linux-alpha@vger.kernel.org Cc: Richard Henderson , linux-kernel@vger.kernel.org Subject: [PATCH] alpha: fix FEN fault handling Message-ID: MIME-Version: 1.0 Content-Disposition: inline Sender: Al Viro X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754323805359757002?= X-GMAIL-MSGID: =?utf-8?q?1754323805359757002?= Type 3 instruction fault (FPU insn with FPU disabled) is handled by quietly enabling FPU and returning. Which is fine, except that we need to do that both for fault in userland and in the kernel; the latter *can* legitimately happen - all it takes is this: .global _start _start: call_pal 0xae lda $0, 0 ldq $0, 0($0) - call_pal CLRFEN to clear "FPU enabled" flag and arrange for a signal delivery (SIGSEGV in this case). Fixed by moving the handling of type 3 into the common part of do_entIF(), before we check for kernel vs. user mode. Incidentally, check for kernel mode is unidiomatic; the normal way to do that is !user_mode(regs). The difference is that the open-coded variant treats any of bits 63..3 of regs->ps being set as "it's user mode" while the normal approach is to check just the bit 3. PS is a 4-bit register and regs->ps always will have bits 63..4 clear, so the open-code variant here is actually equivalent to !user_mode(regs). Harder to follow, though... Reproducer above will crash any box where CLRFEN is not ignored by PAL (== any actual hardware, AFAICS; PAL used in qemu doesn't bother implementing that crap). Cc: stable@vger.kernel.org # all way back... Signed-off-by: Al Viro Reviewed-by: Richard Henderson diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c index 8a66fe544c69..d9a67b370e04 100644 --- a/arch/alpha/kernel/traps.c +++ b/arch/alpha/kernel/traps.c @@ -233,7 +233,21 @@ do_entIF(unsigned long type, struct pt_regs *regs) { int signo, code; - if ((regs->ps & ~IPL_MAX) == 0) { + if (type == 3) { /* FEN fault */ + /* Irritating users can call PAL_clrfen to disable the + FPU for the process. The kernel will then trap in + do_switch_stack and undo_switch_stack when we try + to save and restore the FP registers. + + Given that GCC by default generates code that uses the + FP registers, PAL_clrfen is not useful except for DoS + attacks. So turn the bleeding FPU back on and be done + with it. */ + current_thread_info()->pcb.flags |= 1; + __reload_thread(¤t_thread_info()->pcb); + return; + } + if (!user_mode(regs)) { if (type == 1) { const unsigned int *data = (const unsigned int *) regs->pc; @@ -366,20 +380,6 @@ do_entIF(unsigned long type, struct pt_regs *regs) } break; - case 3: /* FEN fault */ - /* Irritating users can call PAL_clrfen to disable the - FPU for the process. The kernel will then trap in - do_switch_stack and undo_switch_stack when we try - to save and restore the FP registers. - - Given that GCC by default generates code that uses the - FP registers, PAL_clrfen is not useful except for DoS - attacks. So turn the bleeding FPU back on and be done - with it. */ - current_thread_info()->pcb.flags |= 1; - __reload_thread(¤t_thread_info()->pcb); - return; - case 5: /* illoc */ default: /* unexpected instruction-fault type */ ;