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 69B27C433EF for ; Mon, 1 Nov 2021 21:15:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3F3C460E54 for ; Mon, 1 Nov 2021 21:15:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230497AbhKAVS2 convert rfc822-to-8bit (ORCPT ); Mon, 1 Nov 2021 17:18:28 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:60078 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbhKAVS1 (ORCPT ); Mon, 1 Nov 2021 17:18:27 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:35836) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mheek-007Fck-MN; Mon, 01 Nov 2021 15:15:50 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:34714 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 1mheej-00B5mV-HN; Mon, 01 Nov 2021 15:15:50 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= Cc: Liao Chang , Paul Walmsley , Palmer Dabbelt , Albert Ou , Nick Kossifidis , jszhang@kernel.org, guoren@linux.alibaba.com, Pekka Enberg , sunnanyong@huawei.com, wangkefeng.wang@huawei.com, changbin.du@intel.com, Alex Ghiti , linux-riscv , LKML , kexec@lists.infradead.org References: <20211030031832.165457-1-liaochang1@huawei.com> <20211030031832.165457-3-liaochang1@huawei.com> <87ee83goju.fsf@disp2133> Date: Mon, 01 Nov 2021 16:15:42 -0500 In-Reply-To: (=?utf-8?Q?=22Bj=C3=B6rn_T=C3=B6pel=22's?= message of "Sun, 31 Oct 2021 12:14:33 +0100") Message-ID: <87a6inbmrl.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1mheej-00B5mV-HN;;;mid=<87a6inbmrl.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18DBOf1ufm8A1FhY1m4kqu+CrD7jATo5Fs= 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 Björn Töpel writes: > On Sat, 30 Oct 2021 at 05:51, Eric W. Biederman wrote: >> >> 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. >> > > It's not machine_kexec -- it's machine_kexec_prepare, which pulls out > the FDT from the image. It looks like MIPS does it similarly. > > (Caveat: I might be confused as well! ;-)) True it is machine_kexec_prepare. But still. copy_from_user does not belong in there. It is not passed a userspace pointer. This looks more like a case for kmap to read a table from the firmware. Even if it someone made sense it definitely does not make sense to make it a conditional copy_from_user. That way lies madness. The entire change is a smell that there is some abstraction that is going wrong, and that abstraction needs to get fixed. Eric