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.9 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 CCE10C43462 for ; Thu, 6 May 2021 15:23:59 +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 900B5610A5 for ; Thu, 6 May 2021 15:23:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 900B5610A5 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=OGKDnCb2GGj3pIbucEKHL/RTW3BSe8QAsjLs5urI6No=; b=LSMunPC8qSqF1SPs/bBFOdUl0 ghuWpIPq7S0v8dG57G23aAjNFRTy48WRExr1ecjyFBCUIMxXqtfLJ6bQh2hOqJ6WXrlTprVht6+Xv 6zgDmWvYpweEFJtHiXXCVeibDgFGi3064RHiuV8tdd0tls98bAJwgQuiypBBEy/29ZK4/9J0AiDAS TzUZCohRHyQBoWMzriw1DRLQPir9ucXAHcWB6Cms5rF2e9ggPHLBAYGTK71TwNDWqyGMtGUoXM4W1 hqR/UaDH+VSZmdCHY7sVfxPKtaQA5PthnzWhE4AeoT0QujhW6pN3t9Qk4PqUxn3LiZ1NBkU9mxhpk mjCbJaXsw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lefou-004WtT-Jd; Thu, 06 May 2021 15:21:44 +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 1lefos-004Wt1-6R for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 15:21:42 +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=ij10eVnVpqugw2QLIP3ViHbRsGBsR6yzQN21JiOmf90=; b=F3CdyffFvlqWGU1F1KE4tX+3ot ulNWTrKYGIvRfWcxsdvmnwWnBIgHd2XxoVRwll7+Fu2nRcn0Ozy28M7VEMEA1RFhEjkCtjm3GzFBb W2KZt5USVsgi5EB6heht9Vq4EI/aSMcdJxHEj20CAKdcQYQ9igxDSBC0vDYA9AfRAaADhgV1MV+Xh oCFdUNHob6LDVlZeGnPLNa2uYAYyTbUi4xiOj5HK0pW0LSUxiK+v42yNTVbuHE10SJLE7t+BAG2BG 4B4qBkpUlzGF9OYuNA9XpEAEmH25bhCZFFLp/xdQaZAxGuw+dL9qU1+qlighPpB5F4ELYjTsIqZpe Egn311rA==; Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lefop-0068Ek-ON for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 15:21:40 +0000 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id A6B3720B7178; Thu, 6 May 2021 08:21:38 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com A6B3720B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1620314499; bh=ij10eVnVpqugw2QLIP3ViHbRsGBsR6yzQN21JiOmf90=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mpdw5YkqKssIRCZojCamtXzac0zjvErli9rYCXTk1UNKI0RaGDYnJ6JXSuhZ5+Uwx S8GI7LbZ6tBrd6JaZd5l0bPymmvFpKTgtGNBopqZEOrn+f/e/pFzML74XW6XPUVuVG D9kOIHoPn6x+Nb4W6Uk2IoI2/vUZvZf81ECsGcfs= Subject: Re: [RFC PATCH v3 2/4] arm64: Check the return PC against unreliable code sections To: Mark Brown Cc: jpoimboe@redhat.com, mark.rutland@arm.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <65cf4dfbc439b010b50a0c46ec500432acde86d6> <20210503173615.21576-1-madvenka@linux.microsoft.com> <20210503173615.21576-3-madvenka@linux.microsoft.com> <20210504160508.GC7094@sirena.org.uk> <1bd2b177-509a-21d9-e349-9b2388db45eb@linux.microsoft.com> <0f72c4cb-25ef-ee23-49e4-986542be8673@linux.microsoft.com> <20210505164648.GC4541@sirena.org.uk> <9781011e-2d99-7f46-592c-621c66ea66c3@linux.microsoft.com> <20210506134542.GD4642@sirena.org.uk> From: "Madhavan T. Venkataraman" Message-ID: <67969f7f-1c2d-c287-dbdb-4ce21bd8ef23@linux.microsoft.com> Date: Thu, 6 May 2021 10:21:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210506134542.GD4642@sirena.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_082139_873242_1FA3D70B X-CRM114-Status: GOOD ( 22.02 ) 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 5/6/21 8:45 AM, Mark Brown wrote: > On Wed, May 05, 2021 at 01:48:21PM -0500, Madhavan T. Venkataraman wrote: >> On 5/5/21 11:46 AM, Mark Brown wrote: > >>> I think that works even if it's hard to love the goto, might want some >>> defensiveness to ensure we can't somehow end up in an infinite loop with >>> a sufficiently badly formed stack. > >> I could do something like this: > >> unwind_frame() >> { >> int i; >> ... >> >> for (i = 0; i < MAX_CHECKS; i++) { >> if (!check_frame(tsk, frame)) >> break; >> } > > I think that could work, yes. Have to see the actual code (and other > people's opinions!). > >> If this is acceptable, then the only question is - what should be the value of >> MAX_CHECKS (I will rename it to something more appropriate)? > > I'd expect something like 10 to be way more than we'd ever need, or we > could define it down to the 2 checks we expect to be possible ATM to be > conservative. I'm tempted to be permissive if we have sufficient other > checks but I'm not 100% sure on that. > OK. I will implement these changes for version 4 and send it out so this whole thing can be reviewed again with the actual changes in front of us. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel