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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01E10C433F5 for ; Sat, 30 Oct 2021 03:54:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C8B7F6115C for ; Sat, 30 Oct 2021 03:54:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231638AbhJ3DwW (ORCPT ); Fri, 29 Oct 2021 23:52:22 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:47228 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229921AbhJ3DwV (ORCPT ); Fri, 29 Oct 2021 23:52:21 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:59486) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mgfNL-002uma-RR; Fri, 29 Oct 2021 21:49:47 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:47698 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mgfNI-005pIg-Du; Fri, 29 Oct 2021 21:49:47 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Liao Chang Cc: , , , , , , , , , , , , , References: <20211030031832.165457-1-liaochang1@huawei.com> <20211030031832.165457-3-liaochang1@huawei.com> Date: Fri, 29 Oct 2021 22:49:09 -0500 In-Reply-To: <20211030031832.165457-3-liaochang1@huawei.com> (Liao Chang's message of "Sat, 30 Oct 2021 11:18:31 +0800") Message-ID: <87ee83goju.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mgfNI-005pIg-Du;;;mid=<87ee83goju.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18f7M3MHRYDgl23l5rWQ+6xsslUtaUkAZ0= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 2/3] RISC-V: use memcpy for kexec_file mode X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Liao Chang writes: > The pointer to buffer loading kernel binaries is in kernel space for > kexec_fil mode, When copy_from_user copies data from pointer to a block > of memory, it checkes that the pointer is in the user space range, on > RISCV-V that is: > > static inline bool __access_ok(unsigned long addr, unsigned long size) > { > return size <= TASK_SIZE && addr <= TASK_SIZE - size; > } > > and TASK_SIZE is 0x4000000000 for 64-bits, which now causes > copy_from_user to reject the access of the field 'buf' of struct > kexec_segment that is in range [CONFIG_PAGE_OFFSET - VMALLOC_SIZE, > CONFIG_PAGE_OFFSET), is invalid user space pointer. > > This patch fixes this issue by skipping access_ok(), use mempcy() instead. I am a bit confused. Why is machine_kexec ever calling copy_from_user? That seems wrong in all cases. Even worse then having a copy_from_user is having data that you don't know if you should call copy_from_user on. There is most definitely a bug here. Can someone please sort it out without making the kernel guess what kind of memory it is copying from. Eric > Signed-off-by: Liao Chang > --- > arch/riscv/kernel/machine_kexec.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c > index e6eca271a4d6..4a5db856919b 100644 > --- a/arch/riscv/kernel/machine_kexec.c > +++ b/arch/riscv/kernel/machine_kexec.c > @@ -65,7 +65,9 @@ machine_kexec_prepare(struct kimage *image) > if (image->segment[i].memsz <= sizeof(fdt)) > continue; > > - if (copy_from_user(&fdt, image->segment[i].buf, sizeof(fdt))) > + if (image->file_mode) > + memcpy(&fdt, image->segment[i].buf, sizeof(fdt)); > + else if (copy_from_user(&fdt, image->segment[i].buf, sizeof(fdt))) > continue; > > if (fdt_check_header(&fdt))