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 X-Spam-Level: X-Spam-Status: No, score=-4.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D136C433E0 for ; Thu, 30 Jul 2020 01:09:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 01FE2207F5 for ; Thu, 30 Jul 2020 01:09:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="jL5PSsBg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01FE2207F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 71E426B0002; Wed, 29 Jul 2020 21:09:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A7A56B0005; Wed, 29 Jul 2020 21:09:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56E8A6B0006; Wed, 29 Jul 2020 21:09:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id 3E7FC6B0002 for ; Wed, 29 Jul 2020 21:09:09 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E86538400 for ; Thu, 30 Jul 2020 01:09:08 +0000 (UTC) X-FDA: 77092958376.01.trip29_20003d126f77 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id B96DF1004BE27 for ; Thu, 30 Jul 2020 01:09:08 +0000 (UTC) X-HE-Tag: trip29_20003d126f77 X-Filterd-Recvd-Size: 7834 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jul 2020 01:09:08 +0000 (UTC) Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 457902074B; Thu, 30 Jul 2020 01:09:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596071347; bh=TswWeoP8M0WaG5VC/mGNEtkfyyPr2p2vDX8T2CicOqo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jL5PSsBgnU5manfhdob8yg1u89clnWVnjQeRzlXIsBviSsEmu+iLFWqHgnrgtv9aM EWOZOBHXdYGVmE8LS2z4x4VMtPrpzvrAU9/qjWWbJ8sAzn6UG+6oydkw73PeXWhzjQ baxcMDjGDRrzc4e9/x2jIHHqzoRXforSoasIEIQA= Date: Thu, 30 Jul 2020 10:09:02 +0900 From: Masami Hiramatsu To: Ard Biesheuvel Cc: Mike Rapoport , Jarkko Sakkinen , Ingo Molnar , Linux Kernel Mailing List , linux-mm@kvack.org, Andi Kleen , Peter Zijlstra , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Jessica Yu Subject: Re: [PATCH v5 5/6] kprobes: Use text_alloc() and text_free() Message-Id: <20200730100902.c5fa86a87a72ced0bce3dcf4@kernel.org> In-Reply-To: References: <20200724050553.1724168-1-jarkko.sakkinen@linux.intel.com> <20200724050553.1724168-6-jarkko.sakkinen@linux.intel.com> <20200724092746.GD517988@gmail.com> <20200725031648.GG17052@linux.intel.com> <20200726081408.GB2927915@kernel.org> <20200728171715.0800093e2226e3d72b04a3ae@kernel.org> <20200728223545.ce4ff78cac73b571a27bb357@kernel.org> <20200729105054.06f74749eb933c08342e6dd6@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B96DF1004BE27 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 29 Jul 2020 09:13:21 +0300 Ard Biesheuvel wrote: > On Wed, 29 Jul 2020 at 04:51, Masami Hiramatsu wrote: > > > > On Tue, 28 Jul 2020 20:51:08 +0300 > > Ard Biesheuvel wrote: > > > > > On Tue, 28 Jul 2020 at 16:35, Masami Hiramatsu wrote: > > > > > > > > On Tue, 28 Jul 2020 13:56:43 +0300 > > > > Ard Biesheuvel wrote: > > > > > > > > > On Tue, 28 Jul 2020 at 11:17, Masami Hiramatsu wrote: > > > > > > > Masami or Peter should correct me if I am wrong, but it seems to me > > > > > > > that the way kprobes uses these pages does not require them to be in > > > > > > > relative branching range of the core kernel on any architecture, given > > > > > > > that they are populated with individual instruction opcodes that are > > > > > > > executed in single step mode, and relative branches are emulated (when > > > > > > > needed) > > > > > > > > > > > > Actually, x86 and arm has the "relative branching range" requirements > > > > > > for the jump optimized kprobes. For the other architectures, I think > > > > > > we don't need it. Only executable text buffer is needed. > > > > > > > > > > > > > > > > Thanks for the explanation. Today, arm64 uses the definition below. > > > > > > > > > > void *alloc_insn_page(void) > > > > > { > > > > > return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END, > > > > > GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS, > > > > > NUMA_NO_NODE, __builtin_return_address(0)); > > > > > } > > > > > > > > > > Do you think we could use that as the generic implementation if we use > > > > > MODULES_START/_END as the allocation window? > > > > > > > > Yes, but for the generic implementation, we don't need to consider the > > > > relative branching range since we can override it for x86 and arm. > > > > (and that will be almost same as module_alloc() default code) > > > > > > Indeed. So having kprobes specific macros that default to > > > VMALLOC_START/END but can be overridden would be sufficient. > > > > > > > BTW, is PAGE_KERNEL_ROX flag available generically? > > > > > > > > > > Turns out that it is not :-( > > > > Hmm, in that case, we need to use PAGE_KERNEL_EXEC. > > > > In the result, may it be similar to this? :) > > > > void * __weak module_alloc(unsigned long size) > > { > > return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, > > GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, > > NUMA_NO_NODE, __builtin_return_address(0)); > > } > > > > The major difference between module_alloc() and kprobe's alloc_page_insn() > > is the alloc_page_insn() makes the page ROX after allocating the pages *ONLY* > > on x86 and arm64. > > > > Right. > > > $ git grep -w alloc_insn_page -- arch > > arch/arm64/kernel/probes/kprobes.c:void *alloc_insn_page(void) > > arch/x86/kernel/kprobes/core.c:void *alloc_insn_page(void) > > > > However since the module_alloc() owns its arch-dependent implementations > > most of major architectures, if we implement independent text_alloc_kprobe(), > > we need to make deadcopies of module_alloc() for each architecture. > > > > No, that is what we are trying to avoid. > > > $ git grep 'module_alloc(unsigned' arch/ > > arch/arm/kernel/module.c:void *module_alloc(unsigned long size) > > arch/arm64/kernel/module.c:void *module_alloc(unsigned long size) > > arch/mips/kernel/module.c:void *module_alloc(unsigned long size) > > arch/nds32/kernel/module.c:void *module_alloc(unsigned long size) > > arch/nios2/kernel/module.c:void *module_alloc(unsigned long size) > > arch/parisc/kernel/module.c:void *module_alloc(unsigned long size) > > arch/riscv/kernel/module.c:void *module_alloc(unsigned long size) > > arch/s390/kernel/module.c:void *module_alloc(unsigned long size) > > arch/sparc/kernel/module.c:void *module_alloc(unsigned long size) > > arch/unicore32/kernel/module.c:void *module_alloc(unsigned long size) > > arch/x86/kernel/module.c:void *module_alloc(unsigned long size) > > > > It seems that some constrains for module_alloc() exists for above > > architectures. > > > > Anyway, for kprobe's text_alloc() requirements are > > - It must be executable for the arch which uses a single-step out-of-line. > > (and need to be registered to KASAN?) > > No, kasan shadow is not needed here. OK, I just saw the KASAN shadow was generated (kasan_module_alloc was called) in module_alloc() on x86. So current x86 alloc_insn_page() has it. > > - It must be ROX if implemented (currently only for x86 and arm64) > > x86 does not actually define thr macro, but the result is the same. Yes, alloc_insn_page() for x86 is adding the RO and X flag on the page. > > - It must be in the range of relative branching only for x86 and arm. > > > > So in summary, the generic module_alloc() above can be reused for > kprobes on all arches except x86 and arm64, right? Then we can remove > the call to it, and drop the modules dependency. Yes, that's correct. If there is a generic module_alloc(), kprobes is happy to use it :) Thank you, -- Masami Hiramatsu