Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp765115pxb; Tue, 12 Apr 2022 12:52:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5JWQiMzMreZCNaSFxBu4X1hl/uzImE2hqeH1dZ6VtmgipsRrlzSbTM8eYWcjuhCwWdr1X X-Received: by 2002:a63:140f:0:b0:399:3005:baf5 with SMTP id u15-20020a63140f000000b003993005baf5mr32707409pgl.193.1649793130145; Tue, 12 Apr 2022 12:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649793130; cv=none; d=google.com; s=arc-20160816; b=WjFCT4A//sHz56UENsM09gQY06b13QJlliZva2OKpbHOGzQAIdZ+49nhhr/4f7rumC XjRAYMr/3SwteDvj5lIbuxhD7ueShM0lJMhcGG2qj3PoUV6km+SocN0uVsdmN906WHVg ZgnoGbTIW9xM72n13pSn8SM/yXxWrOSSf5M5blU+rNjsrUCC/3k+TMrZQrA0aBWz7et8 78+7BdDj8YNrRfcWEoNNCxIk6HkaSafZ8QqQgK4Fx6tz7GKka9JcmPRVen8JsLP13VD6 Q3vuLdIwd3r+wsdkccDuJLesx+1BzxNax1EToVTZj9jsxFdsanvHw0U+JO8ZeXvuNdrp eWbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=kl8MI7omRRAEGJuLzIemIWDrzNJT0WXRIE0/LnLHB0U=; b=JNkDsMtjLAJL1CGBCSIm96WfPcYwvxx1IyUM4C0aoqILNuIkkWoAinvUzezxv24SVr IY75vEKMMMFMKJNLM2GYLFV+CX+Z1AW9VVnG7axnywEkkkS7KeIVaDJWp06T3X3t8Avz LA5nFDW9FSY4mjZ/SgE9jgb/NPUTnH/GbnkCCyu178C89yoir+bMRjTTrQ81W9Yx0hYC 919OBhLb20TaMLPq5apFAB4ZIb7+D/MkThUKVE4cSJ05Z3j0OxtZmDexXAjB4z493efK sXCro65CWXC9JV07nBwGyDtCoezrhEqHHqvsCzaSbbXs2XXiPKl7cpdLk1QIji17RSpO jsrQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id c1-20020a17090a020100b001cb955dea08si7436177pjc.84.2022.04.12.12.52.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 12:52:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BDB526EC4C; Tue, 12 Apr 2022 12:48:01 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357979AbiDLRLF (ORCPT + 99 others); Tue, 12 Apr 2022 13:11:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350498AbiDLRLD (ORCPT ); Tue, 12 Apr 2022 13:11:03 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D528060AB7 for ; Tue, 12 Apr 2022 10:08:45 -0700 (PDT) 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 8CE6A1424; Tue, 12 Apr 2022 10:08:45 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 086BD3F5A1; Tue, 12 Apr 2022 10:08:37 -0700 (PDT) Message-ID: <38c6d4b5-a3db-5c3e-02e7-39875edb3476@arm.com> Date: Tue, 12 Apr 2022 18:08:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH -next V3 4/6] arm64: add copy_{to, from}_user to machine check safe Content-Language: en-GB To: Tong Tiangen , Mark Rutland , James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , x86@kernel.org, "H . Peter Anvin" Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang , Xie XiuQi References: <20220412072552.2526871-1-tongtiangen@huawei.com> <20220412072552.2526871-5-tongtiangen@huawei.com> From: Robin Murphy In-Reply-To: <20220412072552.2526871-5-tongtiangen@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 On 12/04/2022 8:25 am, Tong Tiangen wrote: [...] > diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h > index 0557af834e03..bb17f0829042 100644 > --- a/arch/arm64/include/asm/asm-uaccess.h > +++ b/arch/arm64/include/asm/asm-uaccess.h > @@ -92,4 +92,20 @@ alternative_else_nop_endif > > _asm_extable 8888b,\l; > .endm > + > + .macro user_ldp_mc l, reg1, reg2, addr, post_inc > +8888: ldtr \reg1, [\addr]; > +8889: ldtr \reg2, [\addr, #8]; > + add \addr, \addr, \post_inc; > + > + _asm_extable_uaccess_mc 8888b, \l; > + _asm_extable_uaccess_mc 8889b, \l; > + .endm You're replacing the only user of this, so please just s/_asm_extable/_asm_extable_uaccess_mc/ in the existing macro and save the rest of the churn. Furthermore, how come you're not similarly updating user_stp, given that you *are* updating the other stores in copy_to_user? > + > + .macro user_ldst_mc l, inst, reg, addr, post_inc > +8888: \inst \reg, [\addr]; > + add \addr, \addr, \post_inc; > + > + _asm_extable_uaccess_mc 8888b, \l; > + .endm Similarly, I think we can just update user_ldst itself. The two instances that you're not replacing here are bogus anyway, and deserve to be fixed with the patch below first. [...] > @@ -62,7 +63,11 @@ SYM_FUNC_START(__arch_copy_from_user) > ret > > // Exception fixups > -9997: cmp dst, dstin > +9997: mrs esr, esr_el1 // Check exception first > + and esr, esr, #ESR_ELx_FSC > + cmp esr, #ESR_ELx_FSC_EXTABT Should we be checking EC to make sure it's a data abort - and thus FSC is valid - in the first place? I'm a little fuzzy on all the possible paths into fixup_exception(), and it's not entirely obvious whether this is actually safe or not. Thanks, Robin. ----->8----- Subject: [PATCH] arm64: mte: Clean up user tag accessors Invoking user_ldst to explicitly add a post-increment of 0 is silly. Just use a normal USER() annotation and save the redundant instruction. Signed-off-by: Robin Murphy --- arch/arm64/lib/mte.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S index 8590af3c98c0..eeb9e45bcce8 100644 --- a/arch/arm64/lib/mte.S +++ b/arch/arm64/lib/mte.S @@ -93,7 +93,7 @@ SYM_FUNC_START(mte_copy_tags_from_user) mov x3, x1 cbz x2, 2f 1: - user_ldst 2f, ldtrb, w4, x1, 0 +USER(2f, ldtrb w4, [x1]) lsl x4, x4, #MTE_TAG_SHIFT stg x4, [x0], #MTE_GRANULE_SIZE add x1, x1, #1 @@ -120,7 +120,7 @@ SYM_FUNC_START(mte_copy_tags_to_user) 1: ldg x4, [x1] ubfx x4, x4, #MTE_TAG_SHIFT, #MTE_TAG_SIZE - user_ldst 2f, sttrb, w4, x0, 0 +USER(2f, sttrb w4, [x0]) add x0, x0, #1 add x1, x1, #MTE_GRANULE_SIZE subs x2, x2, #1 -- 2.28.0.dirty