Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2213687pxb; Tue, 23 Feb 2021 01:06:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/0aKyFv6zokABnOMyfaC8BGNgo+zeshy0FS8ZpQqUHYbljxR73MsEZl9I9bmrVBPE/aAA X-Received: by 2002:a50:fe86:: with SMTP id d6mr26911098edt.80.1614071185609; Tue, 23 Feb 2021 01:06:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614071185; cv=none; d=google.com; s=arc-20160816; b=pTtKkJCIKpXWKgY+qs+g5/3QdVHHLqR8bQbYmDDAxAey6f5GUZxlMBd9GyHl8zqVVL 7AuollltPFwJZM6hqntAZOYB/FP7B9oWGYpibTQOj76L4Z2/V7ZfLZsLyR4F8+FzqA6f yLzmOQdtslE+1GNaGpEU5YmslrJqgifsJaP401PPcHASRF5ol+AbiRg/ri67hQvKS+Kg WyKuD8MhlH6ZBpLreQtqPGilfidWFntCsBbncuI2xYS3ingjATZYmObXN8ggAcuW3lHM F2PLCMaC4pn0DLXPv1qKlmuEQVjjgzGYZl8hzWAVnTdLyBxXo4N31IxTZ5hap95N49DF Vvrw== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=9gF/zAHqM40ppSOEDsPCeBBhvJHDDovaoUb7SXWzjZo=; b=NGvnOiTezSNA4mnADqB6iN5SGJ2JhrzbNzkPOkbMBLmhSMjN2tf/vwbC42SD9Kl/bK VqtyrFRtgWtjEebv9BVrao875CY+eXiahiwtXbvJlGR5FG6z3A36bin4cz8PfdSS+X3Z hOtbiTInUlijrCfTagT7SQHTrIAdbBMakeafsJyI1ORnONx9VIUbkw/x0dYON9zKB+X3 LmnXRWgKZcR4Q1jcHlW6UFKTluA/QrVEifwh72apvPEAnqlOxpCX5Sl4l5rbQjx54Vu1 /w4hAdNx16zbcLj+qDPrrFR/6W1nLjZ7WMjTAa8fL1oTqRVNvupA4rFAH5R4qP+7Se6Z trhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FJCiS3Yd; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk7si15158910ejb.223.2021.02.23.01.05.59; Tue, 23 Feb 2021 01:06: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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FJCiS3Yd; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230467AbhBWHhF (ORCPT + 99 others); Tue, 23 Feb 2021 02:37:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:36838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230166AbhBWHhE (ORCPT ); Tue, 23 Feb 2021 02:37:04 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A9F3A64E4B; Tue, 23 Feb 2021 07:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614065783; bh=FvcM0AlpS10Bx968xckW6qptwwLBmNi7QLxFOYumjy4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FJCiS3YdwcP9dNsAzgc4Kp95A1Bs+TmYroeaW4WTvcK4jzKDn8Wy6e6bfpfNIH5KA ZWTDId3m1iMRNVUvL6X68gM2X+R6VTiLZYPWyiZDKs1Z3bkm97RLHRAxnO0QgJSMKt q6nYspXflkasuxT5Irw4oiRwpTxj4tIoJ+QB2mNm6fXTGUVUSfTAJB91K3xq7H69ZT TYFDsEMnohcu+WnatR2lyCy/JO+rvbKjGPNhpk4HWZgx0mH0ryn2bd+4+zKisJkWFS /dyadvOwPkhTw3kDsR9AnZzudfCmhxhk+bOWSfk/m9Se2L7Uf6+6WrkglovRma8qwN uiPq0YMGUNjUg== Date: Tue, 23 Feb 2021 16:36:19 +0900 From: Masami Hiramatsu To: Masami Hiramatsu Cc: Josh Poimboeuf , Evgenii Shatokhin , Arnaldo Carvalho de Melo , Kristen Carlson Accardi , live-patching@vger.kernel.org, Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Konstantin Khorenko Subject: Re: 'perf probe' and symbols from .text. Message-Id: <20210223163619.0cd580a4290165208c8aa7bb@kernel.org> In-Reply-To: <20210223102331.147d62de88886a75013c10e0@kernel.org> References: <09257fb8-3ded-07b0-b3cc-55d5431698d8@virtuozzo.com> <20210223000508.cab3cddaa3a3790525f49247@kernel.org> <20210222175150.yxgw3sxxaqjqgq56@treble> <20210223102331.147d62de88886a75013c10e0@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Feb 2021 10:23:31 +0900 Masami Hiramatsu wrote: > On Mon, 22 Feb 2021 11:51:50 -0600 > Josh Poimboeuf wrote: > > > On Tue, Feb 23, 2021 at 12:05:08AM +0900, Masami Hiramatsu wrote: > > > > Of course, one could place probes using absolute addresses of the > > > > functions but that would be less convenient. > > > > > > > > This also affects many livepatch modules where the kernel code can be > > > > compiled with -ffunction-sections and each function may end up in a > > > > separate section .text.. 'perf probe' cannot be used > > > > there, except with the absolute addresses. > > > > > > > > Moreover, if FGKASLR patches are merged > > > > (https://lwn.net/Articles/832434/) and the kernel is built with FGKASLR > > > > enabled, -ffunction-sections will be used too. 'perf probe' will be > > > > unable to see the kernel functions then. > > > > > > Hmm, if the FGKASLAR really randomizes the symbol address, perf-probe > > > should give up "_text-relative" probe for that kernel, and must fallback > > > to the "symbol-based" probe. (Are there any way to check the FGKASLR is on?) > > > The problem of "symbol-based" probe is that local (static) symbols > > > may share a same name sometimes. In that case, it can not find correct > > > symbol. (Maybe I can find a candidate from its size.) > > > Anyway, sometimes the security and usability are trade-off. > > > > We had a similar issue with FGKASLR and live patching. The proposed > > solution is a new linker flag which eliminates duplicates: -z > > unique-symbol. > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26391 > > Interesting, but it might not be enough for perf-probe. > Since the perf-probe has to handle both dwarf and elf, both must be > changed. I think the problem is that the dwarf is generated while > compiling, but this -z seems converting elf symbols in linkage. > As far as I can see, this appends ".COUNT" suffix to the non-unique > symbols in the linkage phase. Is that also applied to dwarf too? Ah, OK. If there is an offline elf binary with symbol map, I can convert DWARF symbol -> address -> offline elf symbol (unique name)-> kallsyms. Currently, it directly converts address by kallsyms, so I will change it to find elf-symbol and solve address by kallsyms in post processing. Thank you, -- Masami Hiramatsu