Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1949336pxb; Sun, 31 Oct 2021 04:29:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye1zg/3zLf34q6Y3xiJL5tWumwacbCcH+y6VkdOOFoA9EmotBWNWOU8H+u9LcQw0KqwKiF X-Received: by 2002:a05:6e02:1686:: with SMTP id f6mr15367378ila.123.1635679785081; Sun, 31 Oct 2021 04:29:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635679785; cv=none; d=google.com; s=arc-20160816; b=wCm6iNFh/4j5DptN+mZGpsvbV2/Iti4iGbrXSkc8n8igKi3uUFIexiSie2xuADzdvN hGvhsd365dya/R2NUhejuEp4f1EteQcaC6n6+uj6g+PCDeYaBcJ/ObMyp3NnUkJ5+s5X SDKxeG1srhJ9GYSXkU9z05hNxGWlqprROYrYLL4mejJm4nsGMT1F4JxhTZcwO445mVVb L2WZ0g3ozWfnM9hAnno9FSqyim99eiW6NeNDNoFXc8Rbw0hbw4BbLuF4+6t1BS/V8m8o +eqeulOCyiILnGp/CG9vrkBOWa3IWMuoO1I1BHYnc1j9cgmJwvMecxUppPE+SfyRUhp3 e0vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=61FvhhsNkrh8p46sRtRayu7rrrGsE6so+sH35+PNfww=; b=HAXwOkQcsub1fmM51VBI1hPDFfOkJ5v7JcuySiUwwASGXbtMKoKCKu32bePO6wpm3f kY2N8NRA5Rr+D6Z3VKEP7MoeLg2n1thrnPEGrGR7LcBeyvjpfobtjOICmRs1Zo/QTIIn 2oZcyuLaac9bNNmtdCBMKhBreC97+e7zcdezT4TKgrGD1TymzLMmLWiNavWtP2QWNfl0 /AHh0+/KUKO/8F/HF4JsE8AlXqVXaB0XCQIhsXalrP6hxUM2Xz90ZoQcHR/5962vJvF8 1yGWuZ2lo93ZdPHNsqUOlRFusS11F72p7mAP2oW/ITDBUfK75dr35+pOw7mi1pB/G2ct /ZBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=b+usS8BJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h24si13148997ioe.67.2021.10.31.04.29.01; Sun, 31 Oct 2021 04:29:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=b+usS8BJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229887AbhJaLRS (ORCPT + 99 others); Sun, 31 Oct 2021 07:17:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229697AbhJaLRR (ORCPT ); Sun, 31 Oct 2021 07:17:17 -0400 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F1B9C061570 for ; Sun, 31 Oct 2021 04:14:46 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id d27so5953519wrb.6 for ; Sun, 31 Oct 2021 04:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=61FvhhsNkrh8p46sRtRayu7rrrGsE6so+sH35+PNfww=; b=b+usS8BJfKn+Absvpirb7SiBSJacPaQEjEbGI5s3LhsWIEIXHdP9Yzx1Nqu3+2nbdl 3DoCBuPoU7H7PfLw+uHkXbGk8U5PygtRXFIfqGL6v9R+p3kJ+yJoNwqo8fsFE/wYesQ4 MYd0HadUiQPjx2wF4lyroZYqladcTTbYpq20UZH4FvLpmbZiohAErgWL+4OFXSTF3DoN 8vS/aNWfXR8pptCM/E3/oewqf/hX2JQd9DfNOVd4TtmpaDHfu1FQj58n2JpHWrNaTERV BSQCTCPwXjEmmI+1arOyUzFzfH0ZIY1oGA4GICP5Xqdzk8eZTU+T/3Duti1QHQ8K0Z4K PIRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=61FvhhsNkrh8p46sRtRayu7rrrGsE6so+sH35+PNfww=; b=tfPNkB4hS9HlfiWXzTR4TfPdL3L3T1n5JD/5ZVHraem2I508ZmhFMZtzQACBAjM2PN PIHtAeW7zgfpQOJeYOJN4nr8+tNyeqDjzDsnqzoakfKNzCl009YkBxAN2me/X/k8+jwt Gs2/WLsW4UQBcmLzmoyDSfLM03aN4uusFAXB89EciwXboHltBmBYTWPFwwlZHZREqr2d NlsJX08swRNdDYUGabugD7SQ6tqvRhOPJ6kC9GoYk77/9nnubHHeMM3fIaNa4Uju55Sb FT3aDm3snsUacl3yUMadufuV/sKC16IHNjINkLj7Shizov+CUkcD2EyepGXGkVAzyzBp 8vDw== X-Gm-Message-State: AOAM530zH6ELm06K4La5mhLkFpnmXJe3Dgb2fVNnxCZhfwn2MgO84x4q E24lt1MAI3HyQ2gwrmefn2a5Zcqrrv4r5OwBrTM= X-Received: by 2002:a05:6000:2c6:: with SMTP id o6mr28912160wry.321.1635678884816; Sun, 31 Oct 2021 04:14:44 -0700 (PDT) MIME-Version: 1.0 References: <20211030031832.165457-1-liaochang1@huawei.com> <20211030031832.165457-3-liaochang1@huawei.com> <87ee83goju.fsf@disp2133> In-Reply-To: <87ee83goju.fsf@disp2133> From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Date: Sun, 31 Oct 2021 12:14:33 +0100 Message-ID: Subject: Re: [PATCH 2/3] RISC-V: use memcpy for kexec_file mode To: "Eric W. Biederman" 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Oct 2021 at 05:51, Eric W. Biederman wro= te: > > 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 <=3D TASK_SIZE && addr <=3D 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() inste= ad. > > 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! ;-)) Bj=C3=B6rn