Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4204433pxu; Mon, 30 Nov 2020 21:45:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJwj6w+C2CyKh7MiWGLReiD8x3wsLN7inlegDfEWMqBRfZPUmz1zmw0EdIRTJtyvWcwiQY1h X-Received: by 2002:aa7:d711:: with SMTP id t17mr1336665edq.83.1606801525286; Mon, 30 Nov 2020 21:45:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606801525; cv=none; d=google.com; s=arc-20160816; b=yIclJlHbWbAOx6Z0ph2L3L+r7jymm9UHydJ4Lhr0VDwkUi7PvjmBQe5tUPzxXpHZm0 vc9fFmo6doEtLqLYmiPZIarPTREu/NmeNBd264Xjin33pjCAOwKP9FP431h3B+itNFkE fFdA2DaQ/kJnYciNJ0fwaTBJzsiwLerlnuKaiJjIXNELntRsZSBovf9ini6HjzkXTyyd qmjjZznmuhFhjSjMEjrnEGA1EKmpdLzAnGjvGHJGDiDe1EfSQH+70b3oxDgSt3c0dmpJ zpMlBciGU08yq7AQWdD+7yzIFuwZ8lE85sk5FAXHXzaXQ527kpxUJJGZMXIcL7ylybAn DO5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=i/Xh+Uxhnb/36Y58+xZP00m/rPD7MtNr5bRNT9LqKIk=; b=eodE+AXNn9vsS5leAGF6WkQ+WR1IEVp3iFrqVh48Kqm3zP6R4R5Kw/ALiRRZrvlQ7B sg6q8C/dZndjQWVlaxCsWmTC4DieJEywgIrObIvzI8hX0GTus0d398Ucw4GnwmSLzvxF 3sL5BqGkmTKpaA3V1WJhW5Jg8o9BxAE5teeBKkuslMjPEjcPIq23TC8u/suiiKOC0stu fGqno/txyQo2tTaLGIn3wox8Q8v84WnHJkSmo+fORvc5oLoT4fsVqbYXN9OFAHLEJR0P dDpeY9AQIy1k3KsBI1zi3ubfAbLQGodVF6p4ypzt6WRpam10Ux0Zit1gD1qd6sI2ZCe6 xN9g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q2si294683ejd.502.2020.11.30.21.45.02; Mon, 30 Nov 2020 21:45:25 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726539AbgLAFds (ORCPT + 99 others); Tue, 1 Dec 2020 00:33:48 -0500 Received: from exmail.andestech.com ([60.248.187.195]:47242 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbgLAFdr (ORCPT ); Tue, 1 Dec 2020 00:33:47 -0500 Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id 0B15XHn0081932; Tue, 1 Dec 2020 13:33:17 +0800 (GMT-8) (envelope-from tesheng@andestech.com) Received: from atcfdc88 (10.0.15.120) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.487.0; Tue, 1 Dec 2020 13:32:56 +0800 Date: Tue, 1 Dec 2020 13:32:57 +0800 From: Eric Lin To: Pekka Enberg CC: LKML , linux-riscv , Michel Lespinasse , Daniel Jordan , Peter Xu , Andrew Morton , Albert Ou , Palmer Dabbelt , Paul Walmsley , "dslin1010@gmail.com" , "Alan Quey-Liang Kao(?????????)" Subject: Re: [PATCH] riscv/mm: Prevent kernel module access user-space memory without uaccess routines Message-ID: <20201201053257.GB7647@atcfdc88> References: <20201130053037.27006-1-tesheng@andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.0.15.120] X-DNSRBL: X-MAIL: ATCSQR.andestech.com 0B15XHn0081932 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 30, 2020 at 04:07:03PM +0800, Pekka Enberg wrote: Hi Pekka, > On Mon, Nov 30, 2020 at 7:33 AM Eric Lin wrote: > > > > In the page fault handler, an access to user-space memory > > without get/put_user() or copy_from/to_user() routines is > > not resolved properly. Like arm and other architectures, > > we need to let it die earlier in page fault handler. > > Fix looks good to me. Can you elaborate on how you found the issue and > how the bug manifests itself? OK, I'll elaborate more on the commit message. > > > > > Signed-off-by: Eric Lin > > Cc: Alan Kao > > --- > > arch/riscv/mm/fault.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > > index 3c8b9e433c67..a452cfa266a2 100644 > > --- a/arch/riscv/mm/fault.c > > +++ b/arch/riscv/mm/fault.c > > @@ -232,6 +232,9 @@ asmlinkage void do_page_fault(struct pt_regs *regs) > > if (user_mode(regs)) > > flags |= FAULT_FLAG_USER; > > > > + if (!user_mode(regs) && addr < TASK_SIZE && unlikely(!(regs->status & SR_SUM))) > > + die(regs, "Accessing user space memory without uaccess routines\n"); > > Let's introduce a die_kernel_fault() helper (similar to arm64, for > example) to ensure same semantics for the different kernel faults. You > can extract the helper from no_context(). OK, I'll add a die_kernel_fault() helper function in v2. Thanks for your review. > > > + > > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr); > > > > if (cause == EXC_STORE_PAGE_FAULT) > > -- > > 2.17.0 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv