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,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 715CDC433B4 for ; Mon, 12 Apr 2021 19:57:30 +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 AB28561206 for ; Mon, 12 Apr 2021 19:57:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AB28561206 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:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I/2ybLYh9z4wPvKc+7HAuAAEDpBRokVJnL1DpYzu3K8=; b=TB1drc0JDNbKZ/Z4xb+y8Ylox b81/k6ezyLyL2tmWZn/PJCt5x5wsbkDKafiRlTAZlcZxaJvwYIo7O+B9ACgof7LTufmVoYRW8dYZi 1z298qbnlIjklODHdpIt24xRICqKmLRFK+So+2uih4WLj2Yhn9hmBdsgmq66q3s3d7TJOV0pD2i8W bdcOtlJwVJ/rcoBKtlR8AplXOKarfSqfvShI/eEnQa/ZJKfiAzFQ9mX15eIIsJcxWwWNL4Q5eRQDU ez9MtKbX0CQeVDFgbvXVyMxrHG+ytGDheroJ9IkZ0sfYb1ISdEB+GAxJ6+Aj+OSkG7IXbkvC8h0TU FxrQ9XMwA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lW2ew-007ZVp-2T; Mon, 12 Apr 2021 19:55:46 +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 1lW2et-007ZVZ-W7 for linux-arm-kernel@desiato.infradead.org; Mon, 12 Apr 2021 19:55:44 +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:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=h2gvJ5oqXftarQ16pvd9FutkrlcdXEhDOKLCNzGzJQ0=; b=B/qhtyYyT5MkvVRpkadEqeovDq X4N1PCZ0VmhH3kIeU4B7M6qaPXjdm5gOfAfop3cW2sNuwK7tYyGe5B8COtp0UGzYlhPt29knxSkTG kjVX3JQoltG3e9ZV2ZcceqrpAa72e7UfD06hG3VGZ0vO4MkYavG2/EVRBCce8lRsIYKss8wmG0/qM MZcp0PaHxexyXIWO4/8Wn9KBBdYB4R7X3pVeq4oi20RNw95TwzEdVMVMbNTe70ilYWcf7uy41/7oJ b9bRSyB/31uYLzyjW462KsUoUKunIuPkMdAcErbwISVpWMD1+dRo+QE5nAgnDJzGTzuoeW9IWnxvn Ct5hrbOA==; Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lW2eq-006WO9-BX for linux-arm-kernel@lists.infradead.org; Mon, 12 Apr 2021 19:55:41 +0000 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id D9CC020B8000; Mon, 12 Apr 2021 12:55:36 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D9CC020B8000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618257337; bh=h2gvJ5oqXftarQ16pvd9FutkrlcdXEhDOKLCNzGzJQ0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Qob3oXb5+R1rog4vksif5LZhrGvetrYNRzhrXhIBDtM0KVtPP51ISu5FlyThZA03t OnQ9oqE2cgFhgN5SZFrTTOoK/L/wNTTtiwSocCAswt0d9SmVCLPb96E8wWZyA6U4du 3lj2SzQRCinCdoNr+PbXitPVpvRd8KzUeE+yny6o= Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks To: Mark Brown , Josh Poimboeuf Cc: 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> From: "Madhavan T. Venkataraman" Message-ID: Date: Mon, 12 Apr 2021 14:55:35 -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: <20210412173617.GE5379@sirena.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210412_125540_476234_0A956888 X-CRM114-Status: GOOD ( 29.54 ) 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/12/21 12:36 PM, Mark Brown wrote: > On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote: >> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: > >>> Further, I believe all the special cases are assembly functions, and >>> most of those are already in special sections to begin with. I reckon >>> it'd be simpler and more robust to reject unwinding based on the >>> section. If we need to unwind across specific functions in those >>> sections, we could opt-in with some metadata. So e.g. we could reject >>> all functions in ".entry.text", special casing the EL0 entry functions >>> if necessary. > >> Couldn't this also end up being somewhat fragile? Saying "certain >> sections are deemed unreliable" isn't necessarily obvious to somebody >> who doesn't already know about it, and it could be overlooked or >> forgotten over time. And there's no way to enforce it stays that way. > > Anything in this area is going to have some opportunity for fragility > and missed assumptions somewhere. I do find the idea of using the > SYM_CODE annotations that we already have and use for other purposes to > flag code that we don't expect to be suitable for reliable unwinding > appealing from that point of view. It's pretty clear at the points > where they're used that they're needed, even with a pretty surface level > review, and the bit actually pushing things into a section is going to > be in a single place where the macro is defined. That seems relatively > robust as these things go, it seems no worse than our reliance on > SYM_FUNC to create BTI annotations. Missing those causes oopses when we > try to branch to the function. > OK. Just so I am clear on the whole picture, let me state my understanding so far. Correct me if I am wrong. 1. We are hoping that we can convert a significant number of SYM_CODE functions to SYM_FUNC functions by providing them with a proper FP prolog and epilog so that we can get objtool coverage for them. These don't need any blacklisting. 2. If we can locate the pt_regs structures created on the stack cleanly for EL1 exceptions, etc, then we can handle those cases in the unwinder without needing any black listing. I have a solution for this in version 3 that does it without encoding the FP or matching values on the stack. I have addressed all of the objections so far on that count. I will send the patch series out soon. 3. We are going to assume that the reliable unwinder is only for livepatch purposes and will only be invoked on a task that is not currently running. The task either voluntarily gave up the CPU or was pre-empted. We can safely ignore all SYM_CODE functions that will never voluntarily give up the CPU. They can only be pre-empted and pre-emption is already handled in (2). We don't need to blacklist any of these functions. 4. So, the only functions that will need blacklisting are the remaining SYM_CODE functions that might give up the CPU voluntarily. At this point, I am not even sure how many of these will exist. One hopes that all of these would have ended up as SYM_FUNC functions in (1). So, IMHO, placing code in a black listed section should be the last step and not the first one. This also satisfies Mark Rutland's requirement that no one muck with the entry text while he is sorting out that code. I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the remaining ones to see which ones must be blacklisted, if any. Do you agree? Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel