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 38FB0C47DDF for ; Tue, 30 Jan 2024 12:01:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB8B96B0075; Tue, 30 Jan 2024 07:01:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A41836B007D; Tue, 30 Jan 2024 07:01:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BA926B007E; Tue, 30 Jan 2024 07:01:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 735346B0075 for ; Tue, 30 Jan 2024 07:01:38 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4AD5FA1925 for ; Tue, 30 Jan 2024 12:01:38 +0000 (UTC) X-FDA: 81735837876.20.C1335FF Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf16.hostedemail.com (Postfix) with ESMTP id 70C0618000C for ; Tue, 30 Jan 2024 12:01:36 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf16.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706616096; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n0WbJbv6fzoimQXx65ShQdRhm3qiZXY+n9VOiK6k8oY=; b=yi9DtWcmsPaBl7a8Z8ptjgJdhDbpv5F+xFat9D4RxqkFvCrACnmBoEwR3popIz6Q9B5tD5 HtxlxgUppvTN9I2dtWQBMIn7Qw6g5LfXNiGpQEMCWkpYlyAs4bI8/Si0tnkYJC538vOADM TSPQBFr9XllRf1kSNOtqy9LY6wYyR1U= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf16.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706616096; a=rsa-sha256; cv=none; b=J1MgnwG+nYa2/uLvN4OouowrFeNB5s4WH3qM63wZAo2P6+GUu/uk9r7zaZ9mzlp9wPyGQJ 2lQrNDwuB5/FJ5T7uDSwDnarlV1HqvCTM5mr8a681R62nUTKZoTLZX4xu5O96i9ucd0RTo u3e5O+PBjOSF8qi8joUV5vXBSiNqImM= 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 3DDFDDA7; Tue, 30 Jan 2024 04:02:19 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.48.92]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 57FCA3F762; Tue, 30 Jan 2024 04:01:31 -0800 (PST) Date: Tue, 30 Jan 2024 12:01:26 +0000 From: Mark Rutland To: Tong Tiangen Cc: Catalin Marinas , Will Deacon , James Morse , Robin Murphy , Andrey Ryabinin , Alexander Potapenko , Alexander Viro , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, wangkefeng.wang@huawei.com, Guohanjun Subject: Re: [PATCH v10 3/6] arm64: add uaccess to machine check safe Message-ID: References: <20240129134652.4004931-1-tongtiangen@huawei.com> <20240129134652.4004931-4-tongtiangen@huawei.com> <23795738-b86e-7709-bc2b-5abba2e77b68@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23795738-b86e-7709-bc2b-5abba2e77b68@huawei.com> X-Rspam-User: X-Stat-Signature: z4dn7xzkaakuujtcaim49jnkcrmzgg1k X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 70C0618000C X-HE-Tag: 1706616096-767853 X-HE-Meta: U2FsdGVkX1+5AUMAdnvkCB/7I8iYoRXRYsvjymyiuQHWiTq5g95NybHTrdnA3xyeq8FiQG50YqISSR0SyYLyxst+QLBRKRzfFWXljpMmY2lkL3v4QjpgCBnEtzCONywfxNTwcgITjVUMu6Bs32WrCmOMAh17lVKH6aMpV64lCqIlmaPUf7pKznEzA+veSnDn2ylb/lyeD4Pl+ro3HYpP1MplztL0yaK5dYDwgX8+S3Ku9fPS+hwISGurhwOtxVsI2qjJudssX/gkQsdTegvO7ZAvsig0Z8ILCRt1+CHwAz7GVDODJDSmVFREtIMKS4cN+Toh0O/WeODWdg74gQYYz5uACXrOs16TDqmgBACOu1bgkwXQBmz1AvTbpwiOAqumOrIP7aLdhOjI9sIdB76z/7CMJ6WGKHfXCABDqWdT9u/ZlZYautWPvhz3l/uUAb0xYpE1fh0GsZfuAwKNVOhB9KMXeauqw5Ldzg1ErslFM7fCZGljeVXnvNb27sTaD9Wi0m8IWtV1eEVhlBC/IqtiOTWkwHmwCBolhnkv0CD+dtI1J3+EZxwMfNlXUA16T/bPL7AlXFa9hwrjUAxT45FUchLBjPBiiU5VRem7vR1GDerio51pJ/xE8gRPY++JKwsqy68syXUfY/UUcwmmAM2rZOX2a5vcLqUwWND9cHHIHJ7jdZDWNRfCXTuR4kz8eLyO4Fe/fRWBfO+LTT+CjWcdSbbZzt+l25bjSBpThUEyERvnhgJT8u6P9E6xaIKIIyvJV4obMZd8AC7sXArCdPPSgMQ8hI9Z2Ianb50soFMFRxLW5IJtfFiHMdPdvQ+DL44qNjiDUstKsFAH2FK8zqLRZipdogdcJQTkF8sN+1u5HreUUAIQpsQ/QxcH/WpZCXvObGbVtLbLvHdMPu1Bt332D+FK3sKwm2YnNrB1oaY132Z5wc36S0E5k38lYTkI1ac9J+Bjc8WSyA2gggvphH2 Waq9VsSE y62jq/WvTiGW93+8yPr+NdFZiXSWHIrp87cJ2GeBHA2toqYtH84oqamvQ+UnwxKr1F7SdLbSs7EXb+TdwMefuZtDg0G72w0fzSPwM/hL6Bk5LKRC+OJ0UAxwb/S/++jMMhfBi1zZG7RFb6O6m3wkg4WK/22ks253Ja3WZBAonzchPBqTfBGkg0NC4iv8hHVLhy0KgXsKB9JLegBk= 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: List-Subscribe: List-Unsubscribe: On Tue, Jan 30, 2024 at 07:14:35PM +0800, Tong Tiangen wrote: > 在 2024/1/30 1:43, Mark Rutland 写道: > > On Mon, Jan 29, 2024 at 09:46:49PM +0800, Tong Tiangen wrote: > > Further, this change will also silently fixup unexpected kernel faults if we > > pass bad kernel pointers to copy_{to,from}_user, which will hide real bugs. > > I think this is better than the panic kernel, because the real bugs > belongs to the user process. Even if the wrong pointer is > transferred, the page corresponding to the wrong pointer has a memroy > error. I think you have misunderstood my point; I'm talking about the case of a bad kernel pointer *without* a memory error. For example, consider some buggy code such as: void __user *uptr = some_valid_user_pointer; void *kptr = NULL; // or any other bad pointer ret = copy_to_user(uptr, kptr, size); if (ret) return -EFAULT; Before this patch, when copy_to_user() attempted to load from NULL it would fault, there would be no fixup handler for the LDR, and the kernel would die(), reporting the bad kernel access. After this patch (which adds fixup handlers to all the LDR*s in copy_to_user()), the fault (which is *not* a memory error) would be handled by the fixup handler, and copy_to_user() would return an error without *any* indication of the horrible kernel bug. This will hide kernel bugs, which will make those harder to identify and fix, and will also potentially make it easier to exploit the kernel: if the user somehow gains control of the kernel pointer, they can rely on the fixup handler returning an error, and can scan through memory rather than dying as soon as they pas a bad pointer. > In addition, the panic information contains necessary information > for users to check. There is no panic() in the case I am describing. > > So NAK to this change as-is; likewise for the addition of USER() to other ldr* > > macros in copy_from_user.S and the addition of USER() str* macros in > > copy_to_user.S. > > > > If we want to handle memory errors on some kaccesses, we need a new EX_TYPE_* > > separate from the usual EX_TYPE_KACESS_ERR_ZERO that means "handle memory > > errors, but treat other faults as fatal". That should come with a rationale and > > explanation of why it's actually useful. > > This makes sense. Add kaccess types that can be processed properly. > > > > > [...] > > > > > diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c > > > index 478e639f8680..28ec35e3d210 100644 > > > --- a/arch/arm64/mm/extable.c > > > +++ b/arch/arm64/mm/extable.c > > > @@ -85,10 +85,10 @@ bool fixup_exception_mc(struct pt_regs *regs) > > > if (!ex) > > > return false; > > > - /* > > > - * This is not complete, More Machine check safe extable type can > > > - * be processed here. > > > - */ > > > + switch (ex->type) { > > > + case EX_TYPE_UACCESS_ERR_ZERO: > > > + return ex_handler_uaccess_err_zero(ex, regs); > > > + } > > > > Please fold this part into the prior patch, and start ogf with *only* handling > > errors on accesses already marked with EX_TYPE_UACCESS_ERR_ZERO. I think that > > change would be relatively uncontroversial, and it would be much easier to > > build atop that. > > OK, the two patches will be merged in the next release. Thanks. Mark.