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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 26BACC433DF for ; Wed, 29 Jul 2020 06:13:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2B80206D4 for ; Wed, 29 Jul 2020 06:13:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="V5ZJBNCg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2B80206D4 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 25E8E6B0006; Wed, 29 Jul 2020 02:13:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E8856B0007; Wed, 29 Jul 2020 02:13:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B1D26B0008; Wed, 29 Jul 2020 02:13:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id E30E76B0006 for ; Wed, 29 Jul 2020 02:13:35 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9040E8248A9A for ; Wed, 29 Jul 2020 06:13:35 +0000 (UTC) X-FDA: 77090096790.14.fire31_5101f9626f70 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 627FC18229837 for ; Wed, 29 Jul 2020 06:13:35 +0000 (UTC) X-HE-Tag: fire31_5101f9626f70 X-Filterd-Recvd-Size: 7624 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Jul 2020 06:13:34 +0000 (UTC) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9EF3020786 for ; Wed, 29 Jul 2020 06:13:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596003213; bh=u7d5xK7YvZOBGWh1UlpubqMP0fRaHhDT8+EFryfPydc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=V5ZJBNCgjljMU5XeW52AONwfUK28LmE1GLwePhYZwRh/TV4yB7tKR5/xOnSIW36Qk 7gksdnHlZwrQXWefT4b3DZBQFa6BVKeatDFVcQBXPpMdLYvumyucwXpJVNyRZ6raDR o4qdUAY/cSOrN18Y/Z1uYFHF/Z2Uxp0HMJyE5KSQ= Received: by mail-ot1-f53.google.com with SMTP id r21so6192347ota.10 for ; Tue, 28 Jul 2020 23:13:33 -0700 (PDT) X-Gm-Message-State: AOAM531ndef+VhxAAB7s0qOpamvQtr3OptVYfzXjr+zKyFbFRrs9pyBG V3xdtLx5hpIC6wNnHpY+OvAHsjPgpu1yp3glYk4= X-Google-Smtp-Source: ABdhPJzisB9A1LhQj4M7/NTAkUb9eJtp9/Ra3dmt8xSVIi2/rJEIGK31x1dU71fnIQt9LT+836SKAM4L/8rZIFEx0gk= X-Received: by 2002:a9d:3b23:: with SMTP id z32mr9899829otb.77.1596003212957; Tue, 28 Jul 2020 23:13:32 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20200729105054.06f74749eb933c08342e6dd6@kernel.org> From: Ard Biesheuvel Date: Wed, 29 Jul 2020 09:13:21 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 5/6] kprobes: Use text_alloc() and text_free() To: Masami Hiramatsu 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 627FC18229837 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 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. > - 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. > - 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.