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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8D82C433EF for ; Sat, 16 Apr 2022 07:41:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1051D6B0072; Sat, 16 Apr 2022 03:41:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B4C06B0073; Sat, 16 Apr 2022 03:41:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE58D6B0074; Sat, 16 Apr 2022 03:41:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id E1E566B0072 for ; Sat, 16 Apr 2022 03:41:16 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B89041387 for ; Sat, 16 Apr 2022 07:41:16 +0000 (UTC) X-FDA: 79361946552.06.1EC5648 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf29.hostedemail.com (Postfix) with ESMTP id 3F514120008 for ; Sat, 16 Apr 2022 07:41:15 +0000 (UTC) Received: from kwepemi100011.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KgQ8w0Gnyz1HBsJ; Sat, 16 Apr 2022 15:40:32 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi100011.china.huawei.com (7.221.188.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 15:41:11 +0800 Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 15:41:10 +0800 Message-ID: <6252f076-b74a-8dc8-9bc9-93aa70e844c5@huawei.com> Date: Sat, 16 Apr 2022 15:41:09 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [RFC PATCH -next V3 4/6] arm64: add copy_{to, from}_user to machine check safe To: Robin Murphy , Mark Rutland , James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , , "H . Peter Anvin" CC: , , , Kefeng Wang , Xie XiuQi References: <20220412072552.2526871-1-tongtiangen@huawei.com> <20220412072552.2526871-5-tongtiangen@huawei.com> <38c6d4b5-a3db-5c3e-02e7-39875edb3476@arm.com> <306b1b09-487a-9ccd-4a63-8c78889492c6@arm.com> From: Tong Tiangen In-Reply-To: <306b1b09-487a-9ccd-4a63-8c78889492c6@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 3F514120008 X-Stat-Signature: kirsqs661u7tcmrh91tqx55sjgbpwc1q Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspamd-Server: rspam01 X-HE-Tag: 1650094875-447944 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 在 2022/4/13 1:17, Robin Murphy 写道: > On 12/04/2022 6:08 pm, Robin Murphy wrote: > [...] >>> @@ -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. > > In fact, thinking some more about that, I don't think there should be > any need for this sort of logic in these handlers at all. The > fixup_exception() machinery should already know enough about the > exception that's happened and the extable entry to figure this out and > not bother calling the handler at all. > > Thanks, > Robin. > . Hi Robin: As you said, it seems that it's not good to judge esr here, how about using the following method, i need your suggestion :) +#define FIXUP_TYPE_NORMAL 0 +#define FIXUP_TYPE_MC 1 arch/arm64/mm/extable.c static bool ex_handler_fixup(const struct exception_table_entry *ex, - struct pt_regs *regs) + struct pt_regs *regs, int fixuptype) { + regs->regs[16] = fixuptype; [...] } bool fixup_exception(struct pt_regs *regs) { [...] switch(ex->type) { case EX_TYPE_UACCESS_MC: - return ex_handler_fixup(ex, regs) + return ex_handler_fixup(ex, regs, FIXUP_TYPE_NORMAL) break; } [...] } bool fixup_exception_mc(struct pt_regs *regs) { [...] switch(ex->type) { case EX_TYPE_UACCESS_MC: - return ex_handler_fixup(ex, regs) + return ex_handler_fixup(ex, regs, FIXUP_TYPE_MC) break; } [...] } arch/arm64/lib/copy_from_user.S arch/arm64/lib/copy_to_user.S +fixup_type .req x16 // Exception fixups //x16: fixup type written by ex_handler_fixup -9997: cmp dst, dstin +9997: cmp fixup_type, #FIXUP_TYPE_MC + b.eq 9998f + cmp dst, dstin b.ne 9998f Thanks, Tong.