Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4796990ybi; Tue, 28 May 2019 02:40:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZXEAhwxTPs6b0/10WPR5v+fwDQRvz7VtFmFG6OWbvv+TvXur8G24P4lQLFbR2VYox8g23 X-Received: by 2002:a17:90a:bd8b:: with SMTP id z11mr4573278pjr.45.1559036425809; Tue, 28 May 2019 02:40:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559036425; cv=none; d=google.com; s=arc-20160816; b=T8scKsVuTHnZK6WDWmsp7/H6nXvuTEaz6a7N0hNCrLrssrp6R8XhgynaaTMNI6tSLS 6bIlSK1f0zSLd+fB9jk1cCAtQpMpQn1RvEZmnXrsLutqxlLM/VSzRxpiFa2trz+mUFhC OnUFz06Z/AUrJZlqse7phEJ+yhQjGEJAqfeuX/q8hhJ3hFvQNjVPJdTGiA2rZkGrlv4R +4bLkB8JzIHQM9yiI1dEtRHFX6jTCK0I6rVzUZp0XjEjpsiQ8N1Fv3rVe7NSmohxzBpK OlKkb1iPSrQ1JpaYIISoWRMIuDm/5fDL7q16rnNWxBqj7/flrd9inU5ZPF7csb5MgFQ/ XWuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jetKuFwS2RyHrn60T2nVi9Ja0HJ4UR7yb0VYNji6I0g=; b=02QTXfvqH3nTv+oEV0UbsbyE3zMZ2wK8sCS8t+aMw1QIoGeJhodbL3LpmLawEF2WyY mgiL/t2S9cA/2mv5k1ZkBi49jjviC877jOeaT1ckVFXFGs3uuSKIzzTEPMHCxEWOp0Dy I4n8KBPSe9Ygiemo/ubM/flfnGR6pEZqN+l06qeNGfPxcAGdTXBGL51QPo2bMdkPFQoe MmtrN8YwMB+9uhT5tp0mOqenUp7xRPnJDGBN5yJBFnrsrBNNfZY4ZVIDJHsILM2c+kM2 K0k3Il9PGnOlCTDFTFW/fpbZTsoOHOS/Im66ufRNnI5haboXjw6AwLfz4WjOKWGp+TzX Z9KQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x13si2872308pjn.50.2019.05.28.02.40.09; Tue, 28 May 2019 02:40:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726520AbfE1IU3 (ORCPT + 99 others); Tue, 28 May 2019 04:20:29 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51756 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726425AbfE1IU3 (ORCPT ); Tue, 28 May 2019 04:20:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 82DCE341; Tue, 28 May 2019 01:20:28 -0700 (PDT) Received: from [10.162.40.141] (p8cg001049571a15.blr.arm.com [10.162.40.141]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B8A83F59C; Tue, 28 May 2019 01:20:24 -0700 (PDT) Subject: Re: [PATCH 3/4] arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages To: Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Cc: mark.rutland@arm.com, marc.zyngier@arm.com, Will Deacon , linux-kernel@vger.kernel.org, Peter Zijlstra , Nadav Amit , Masami Hiramatsu , James Morse , Andrew Morton , Rick Edgecombe References: <20190523102256.29168-1-ard.biesheuvel@arm.com> <20190523102256.29168-4-ard.biesheuvel@arm.com> From: Anshuman Khandual Message-ID: Date: Tue, 28 May 2019 13:50:36 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190523102256.29168-4-ard.biesheuvel@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/23/2019 03:52 PM, Ard Biesheuvel wrote: > In order to avoid transient inconsistencies where freed code pages > are remapped writable while stale TLB entries still exist on other > cores, mark the kprobes text pages with the VM_FLUSH_RESET_PERMS > attribute. This instructs the core vmalloc code not to defer the > TLB flush when this region is unmapped and returned to the page > allocator. Makes sense. > > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/kernel/probes/kprobes.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > index 2509fcb6d404..036cfbf9682a 100644 > --- a/arch/arm64/kernel/probes/kprobes.c > +++ b/arch/arm64/kernel/probes/kprobes.c > @@ -131,8 +131,10 @@ void *alloc_insn_page(void) > void *page; > > page = vmalloc_exec(PAGE_SIZE); > - if (page) > + if (page) { > set_memory_ro((unsigned long)page, 1); > + set_vm_flush_reset_perms(page); > + } Looks good. It seems there might be more users who would like to set VM_FLUSH_RESET_PERMS right after their allocation for the same reason. Hence would not it help to have a variant like vmalloc_exec_reset() or such which will tag vm_struct->flags with VM_FLUSH_RESET_PERMS right after it's allocation without requiring the caller to do the same.