Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1834345iog; Thu, 16 Jun 2022 15:07:27 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uTS3ENjh1Cn3x5fiBUgBBvIhA0albBiBfHvfoSWToGhCAg1ScWvJADrhWq9/JvEBs7HOq6 X-Received: by 2002:a17:902:f78b:b0:16a:4ad:f359 with SMTP id q11-20020a170902f78b00b0016a04adf359mr147577pln.99.1655417247234; Thu, 16 Jun 2022 15:07:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655417247; cv=none; d=google.com; s=arc-20160816; b=jymU/k7KTPU/DGZD5UMlRXHyZmD+OPUOoyaALSkAoFOtq6i/a7nhEpX9KxdGyEdyF5 vSCCwbl2WkwXltQtHKGzKJLXAQRwjr00n1o0RjKeoZeWTkHgf2TTnkHatPUaKYgMu+0e qYWmR638DjgJYdrPf1hXqghDAZtNIcLnfESYYmK7iJnwDuKkcsbLEyOKjXzz7YTggEgb 5dkI7K6GJVttkSgBkDox+edFQlHmw9Uv7peS3tCaBYithsyI205xtQxCBvY0QiorZ0wM vywfkOApXoCinjBcKObrpphLXm9ZHQrdmaFaTxFok/CZBCPY4IdTqg6jmWM/FOdfXt0L C8jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=zGBZJcSZ/U2W2OG+8NJC+fEKRwdCP8ZVUrkCa1GUjJM=; b=e7zNYpGaPIjAHPrkT0OwfAgIdLqxD1nCQfGx46vHCw8Uq6gkN1p7pOUQd6TEEwbKyr 5fVZeMj3ercJ3+0YEkUBWGsVz3EvC0QeRPKpiX8pdi09arfBws4pkeu45KX8zuL2Z+Y+ SrY+r38KuOTAGTTTMDlnK5UlokwgEJpseLg5MWw44V2ByZcpIC7g2kWfKXvri47zc0EC xmMQXbxJh7Q8ljtdz6Oe+ORF1XjpZMpk3BokO6eky5JbG1CuUpkGPYX+40qsQMw9ndAB JSIZ6qxX7pFCK9kIn0bpXndBIPNwHq3C2vcFumgweG849W8h5Ap5AA8sEUA/Ka1R9AUl SZxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=e0Ru41M0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q4-20020a17090311c400b00166449db813si4434312plh.464.2022.06.16.15.07.11; Thu, 16 Jun 2022 15:07:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=e0Ru41M0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379048AbiFPWFR (ORCPT + 99 others); Thu, 16 Jun 2022 18:05:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378696AbiFPWFB (ORCPT ); Thu, 16 Jun 2022 18:05:01 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77B2D6163D for ; Thu, 16 Jun 2022 15:04:54 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id b12-20020a17090a6acc00b001ec2b181c98so1373151pjm.4 for ; Thu, 16 Jun 2022 15:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=zGBZJcSZ/U2W2OG+8NJC+fEKRwdCP8ZVUrkCa1GUjJM=; b=e0Ru41M0uDOh0SC3RTUpcSh7Nlh3ZyNMHyhCVi3YyHT1OLrQ2v3HzYEEiZEOvuYB5I ZbrKrdxNBGXS6dRyfKMA7k6a5KOG+WXZCfH2Zh08Lzp247mnrGd99VNENM+sDeAXfadB TRDtkfo8Y+dLVRIWh1e4ywDVaKoos9VZDb7WXOyGSHPxKudONRkBvSDtVDmT2qGCUCkI 0Wx7XQXBruiKF5X+xfE+n1eEbujxOgHbUL9V2nsRVh1utDdSxu1KSFSCyNS8OuFns2P5 5KHne5Iy/XNGV9kETMpzEcPy8vjYCYZwJNjQvwJNNpB53Ri2bEdZI2brtRaxXvmP2wYd bpNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=zGBZJcSZ/U2W2OG+8NJC+fEKRwdCP8ZVUrkCa1GUjJM=; b=ARyMRCpIpLmitsA0rE/MiCbTljrPUiI1ft2ync7uCfuOmRhVcWy7IniFQMXGh1DgU7 txALD4jpIqvoQFJYn6SUkaxWTBqLKU4e4zvq2tKAXs2ERkpVNuXYlpF2MCzpU8eJiOoA gPPF0XnUQKKWI6H9iVrTgislu3tkYhBTEPkvkJlPgUQ6jhFX/tSYvsj/CB1BncdrdiXx 09ISwcjGkPo1QZnJGA+6A7iofnye5m4MpF42HRR9o4NQL6AOK86DfqcTTdA/QNNguxiR hrnYAB9lpMDV6vJutPQ8EG7HA3rQETEQ6GUA6zmfALUaM2tZjUDcyOkc8QXMqUNcxtCb O8yA== X-Gm-Message-State: AJIora9zAbflx4dXoO7PIqROALdn6cpHG5P5DChtamj8Ft3PAw1ARuHs GBFDJ7r8dSFr8sNHucY8KRykcA== X-Received: by 2002:a17:902:d2ce:b0:167:7637:7025 with SMTP id n14-20020a170902d2ce00b0016776377025mr6278621plc.37.1655417093786; Thu, 16 Jun 2022 15:04:53 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id g12-20020a62f94c000000b0050dc762816asm2255514pfm.68.2022.06.16.15.04.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 15:04:52 -0700 (PDT) Date: Thu, 16 Jun 2022 15:04:52 -0700 (PDT) X-Google-Original-Date: Thu, 16 Jun 2022 15:04:46 PDT (-0700) Subject: Re: [PATCH] riscv: Invalid instruction cache after copy the xol area In-Reply-To: <20220518081753.29589-1-po-kai.chi@sifive.com> CC: Paul Walmsley , aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, po-kai.chi@sifive.com From: Palmer Dabbelt To: po-kai.chi@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 May 2022 01:17:53 PDT (-0700), po-kai.chi@sifive.com wrote: > We need to invalid the relevant instruction cache after > copying the xol area, to ensure the changes takes effect. > > Signed-off-by: Po-Kai Chi > --- > arch/riscv/kernel/probes/uprobes.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c > index 7a057b5f0adc..9d52beeac73c 100644 > --- a/arch/riscv/kernel/probes/uprobes.c > +++ b/arch/riscv/kernel/probes/uprobes.c > @@ -165,6 +165,7 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr, > /* Initialize the slot */ > void *kaddr = kmap_atomic(page); > void *dst = kaddr + (vaddr & ~PAGE_MASK); > + unsigned long addr = (unsigned long)dst; > > memcpy(dst, src, len); > > @@ -177,10 +178,9 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr, > kunmap_atomic(kaddr); > > /* > - * We probably need flush_icache_user_page() but it needs vma. > - * This should work on most of architectures by default. If > - * architecture needs to do something different it can define > - * its own version of the function. > + * Flush both I/D cache to ensure instruction modification > + * takes effect. > */ > flush_dcache_page(page); > + flush_icache_range(addr, addr + len); > } This brings up a handful of issues: * This always inserts a 32-bit breakpoint, but that's not quite correct. This should really be checking the _next_ instruction as well to insert a 16-bit breakpoint if it's a 16-bit instruction as otherwise userspace might jump into the middle of the breakpoint. * These instructions can be concurrently executing, which relies on some instruction fetch ordering that's very lightly specified. We don't rely on that elsewhere (see stop_machine() in kprobes), but we probably should. It's probably worth adding something to probe the HW to make sure this is supported. * Adding the icache flush defeats a uprobes advantage in that we'll now be triggering remote execution (to do the remote fence.i). One option could be to defer the fence and wait on it, but not sure if that's sane and it'd likely require a lot of This also leaves a bit undefined WRT icache aliasing, at least in terms of the API used. IMO it'd be diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c index 9d52beeac73c..c857346864fc 100644 --- a/arch/riscv/kernel/probes/uprobes.c +++ b/arch/riscv/kernel/probes/uprobes.c @@ -165,7 +165,6 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr, /* Initialize the slot */ void *kaddr = kmap_atomic(page); void *dst = kaddr + (vaddr & ~PAGE_MASK); - unsigned long addr = (unsigned long)dst; memcpy(dst, src, len); @@ -179,8 +178,10 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr, /* * Flush both I/D cache to ensure instruction modification - * takes effect. + * takes effect. We don't need to flush the whole icache, but that's + * all RISC-V defines so rather than worry about aliasing this just + * flushes everything. */ flush_dcache_page(page); - flush_icache_range(addr, addr + len); + flush_icache_all(); } which will end up doing the same thing but avoids the ambiguity. I went ahead and put this at palmer/riscv-uprobe_fencei with that and some other minor things fixed up, LMK if that looks OK and I'll take it on fixes. Thanks!