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=-14.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 CA322C433B4 for ; Fri, 16 Apr 2021 14:44:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A61146115B for ; Fri, 16 Apr 2021 14:44:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245406AbhDPOoa (ORCPT ); Fri, 16 Apr 2021 10:44:30 -0400 Received: from linux.microsoft.com ([13.77.154.182]:34918 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245336AbhDPOoO (ORCPT ); Fri, 16 Apr 2021 10:44:14 -0400 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id E19B320B8001; Fri, 16 Apr 2021 07:43:48 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E19B320B8001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618584229; bh=yGPlUqDIzhuFZFcl7DevIoGiDHKMdjiHRYZvWB7Gcdc=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=ZXSTC27GAO2RgkakprT0jpYfaL73I93QUAJQIV4YrY0mJTa87YTXICpw7uxPx/mYG lw/qz04hxBR7OWsSldaiBNgZUA/CGR5dOKJ9O1ffAIzGn4uHJhKGpO+/J2wVWYulfV goF3hV0R2o8x4WM42VtqTG5MOojqRcDGA30VOj8E= Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks From: "Madhavan T. Venkataraman" To: Mark Brown Cc: Josh Poimboeuf , Mark Rutland , jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210409120859.GA51636@C02TD0UTHF1T.local> <20210409213741.kqmwyajoppuqrkge@treble> <20210412173617.GE5379@sirena.org.uk> <20210413110255.GB5586@sirena.org.uk> <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com> Message-ID: Date: Fri, 16 Apr 2021 09:43:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/14/21 5:23 AM, Madhavan T. Venkataraman wrote: > In any case, I have absolutely no problems in implementing your section idea. I will > make an attempt to do that in version 3 of my patch series. So, I attempted a patch with just declaring all .entry.text functions as unreliable by checking just the section bounds. It does work for EL1 exceptions. But there are other functions that are actually reliable that show up as unreliable. The example in my test is el0_sync() which is at the base of all system call stacks. How would you prefer I handle this? Should I place all SYM_CODE functions that are actually safe for the unwinder in a separate section? I could just take some approach and solve this. But I would like to get your opinion and Mark Rutland's opinion so we are all on the same page. Please let me know. Madhavan 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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 1766FC433B4 for ; Fri, 16 Apr 2021 14:46:38 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9D7E61073 for ; Fri, 16 Apr 2021 14:46:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9D7E61073 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:References: Cc:To:From:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GDTW6+eVXC5usqGtoDlYVe9sZQKkEOBquXM+yiqk21U=; b=NTMq7dwbn/0ec1B34FJgzf9rO YrN2NwAIE/SkGVFdTfOa0zeUrS12CQHlBvAuuLH6wfBYAIVHeBpNh1hCKJMPb7AbL7LmRqQBaB7z0 UqtQQlG2iArh1P8ZHGbXIF9YWjCUjBPGF9BYuL0olEykVH9dWdGnvlDMVs9e1tPFq9hNp6c9OdE8t wDJYcXdstMEpGlxqChSYbbyClFA0+E+SpkLA9p1xb9mvaHcOWX6KPN35uj+tG1NDKdcGqV7tpOPev ZvgrtVIeBQAoaLzasB8mv1JIcjrUbe2d0J5H+GblbrqauI2KRUVNM6idJI6PLVmEe+cch+38y4VHc a7vua6GnQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lXPiC-002T7k-9M; Fri, 16 Apr 2021 14:44:50 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lXPhN-002SrH-53 for linux-arm-kernel@desiato.infradead.org; Fri, 16 Apr 2021 14:43:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=yGPlUqDIzhuFZFcl7DevIoGiDHKMdjiHRYZvWB7Gcdc=; b=mheew4AdmtqrMqNWz8jrptwajR b08qlXwYYougTiHTKbv2Lm/tXIRrUSjnUSAn/iaexw60HtSikeNAAFi+teYx9PmK4bFZe7Fk0p6dy kAKfMW15Qvfg/XWLhlmTLb6SyPFXYd5M9MltvcSxv1LtC/b2rnGlYDy8MMQsOVHbXS6f1+5HBoAj+ GBH1Ef2qeWWeY6Hm22ASf9Kg+ujm6aIsxnDDF6sMpvEvlMBFtn8kyV+QwxU+SQKWVHpWy3+CocpVC XjmBRhAqi7D2mumpPS01SrpP5gDos1PLUEoCB4nmwEWzEw/zADzmnbhItjPxc+pbPguDr8/5cJapp WYElLjLg==; Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lXPhH-009SzF-Is for linux-arm-kernel@lists.infradead.org; Fri, 16 Apr 2021 14:43:55 +0000 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id E19B320B8001; Fri, 16 Apr 2021 07:43:48 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E19B320B8001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618584229; bh=yGPlUqDIzhuFZFcl7DevIoGiDHKMdjiHRYZvWB7Gcdc=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=ZXSTC27GAO2RgkakprT0jpYfaL73I93QUAJQIV4YrY0mJTa87YTXICpw7uxPx/mYG lw/qz04hxBR7OWsSldaiBNgZUA/CGR5dOKJ9O1ffAIzGn4uHJhKGpO+/J2wVWYulfV goF3hV0R2o8x4WM42VtqTG5MOojqRcDGA30VOj8E= Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks From: "Madhavan T. Venkataraman" To: Mark Brown Cc: Josh Poimboeuf , Mark Rutland , jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210409120859.GA51636@C02TD0UTHF1T.local> <20210409213741.kqmwyajoppuqrkge@treble> <20210412173617.GE5379@sirena.org.uk> <20210413110255.GB5586@sirena.org.uk> <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com> Message-ID: Date: Fri, 16 Apr 2021 09:43:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210416_074351_680832_E542B7AB X-CRM114-Status: GOOD ( 10.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/14/21 5:23 AM, Madhavan T. Venkataraman wrote: > In any case, I have absolutely no problems in implementing your section idea. I will > make an attempt to do that in version 3 of my patch series. So, I attempted a patch with just declaring all .entry.text functions as unreliable by checking just the section bounds. It does work for EL1 exceptions. But there are other functions that are actually reliable that show up as unreliable. The example in my test is el0_sync() which is at the base of all system call stacks. How would you prefer I handle this? Should I place all SYM_CODE functions that are actually safe for the unwinder in a separate section? I could just take some approach and solve this. But I would like to get your opinion and Mark Rutland's opinion so we are all on the same page. Please let me know. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel