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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 EA426C43461 for ; Mon, 14 Sep 2020 10:06:17 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 3FF8D20759 for ; Mon, 14 Sep 2020 10:06:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zXnlnAVl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FF8D20759 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+/RSCFUp2Eqj8lJVXDIMmH//cnURRMbFykvXG5eFjWg=; b=zXnlnAVlaG10PQ6zhp1fftQpa LLSiJwHeYhvx+zZmrt2NH5h1Pc9eFM+rGQfrcdU3PL0kyBlS3RKW0pxbQCVpa3rEHV9utauLD4J4w InS3s7OdKUrlYrocUwHpV6wVniXcLM6XRKPdDJuYUvz6XuBpPei3cz6FxoSSqPmtJPymtX6S1JSCR +51cVkWtWGjEkcQQqdc6ia5I0UvvkFGCWjK7rKaRpVPlEnObNPlngYPBTtm3o55WMm1/tPMLeEjqK UNPgBcnXUJJBMgdhLkYyuaFU7gvf5LvkddVoJYrSDl6SahEajZvOo3eyRpEZTay78TuS5AiNPPu5u 4JFs48ZhA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kHlLn-0003bR-SD; Mon, 14 Sep 2020 10:04:43 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kHlLj-0003ZN-Oz for linux-arm-kernel@lists.infradead.org; Mon, 14 Sep 2020 10:04:40 +0000 Received: from gaia (unknown [46.69.195.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8370220735; Mon, 14 Sep 2020 10:04:35 +0000 (UTC) Date: Mon, 14 Sep 2020 11:04:33 +0100 From: Catalin Marinas To: Amit Kachhap Subject: Re: [PATCH v7 4/6] arm64: cpufeature: Modify address authentication cpufeature to exact Message-ID: <20200914100432.GA32700@gaia> References: <20200909140759.4170-1-amit.kachhap@arm.com> <20200909140759.4170-5-amit.kachhap@arm.com> <20200911172418.GL12835@gaia> <8128f714-0f99-1113-de41-03d35b89c5b6@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8128f714-0f99-1113-de41-03d35b89c5b6@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200914_060439_963388_BFD1FB88 X-CRM114-Status: GOOD ( 32.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Suzuki K Poulose , Mark Brown , James Morse , Vincenzo Frascino , Will Deacon , Dave Martin , linux-arm-kernel@lists.infradead.org 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 Mon, Sep 14, 2020 at 12:24:23PM +0530, Amit Kachhap wrote: > On 9/11/20 10:54 PM, Catalin Marinas wrote: > > On Wed, Sep 09, 2020 at 07:37:57PM +0530, Amit Daniel Kachhap wrote: > > > The current address authentication cpufeature levels are set as LOWER_SAFE > > > which is not compatible with the different configurations added for Armv8.3 > > > ptrauth enhancements as the different levels have different behaviour and > > > there is no tunable to enable the lower safe versions. This is rectified > > > by setting those cpufeature type as EXACT. > > > > > > The current cpufeature framework also does not interfere in the booting of > > > non-exact secondary cpus but rather marks them as tainted. As a workaround > > > this is fixed by replacing the generic match handler with a new handler > > > specific to ptrauth. > > > > > > After this change, if there is any variation in ptrauth configurations in > > > secondary cpus from boot cpu then those mismatched cpus are parked in an > > > infinite loop. > > > > > > Following ptrauth crash log is oberserved in Arm fastmodel with mismatched > > > cpus without this fix, > > > > > > CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64ISAR1_EL1. Boot CPU: 0x11111110211402, CPU4: 0x11111110211102 > > > CPU features: Unsupported CPU feature variation detected. > > > GICv3: CPU4: found redistributor 100 region 0:0x000000002f180000 > > > CPU4: Booted secondary processor 0x0000000100 [0x410fd0f0] > > > Unable to handle kernel paging request at virtual address bfff800010dadf3c > > > Mem abort info: > > > ESR = 0x86000004 > > > EC = 0x21: IABT (current EL), IL = 32 bits > > > SET = 0, FnV = 0 > > > EA = 0, S1PTW = 0 > > > [bfff800010dadf3c] address between user and kernel address ranges > > > Internal error: Oops: 86000004 [#1] PREEMPT SMP > > > Modules linked in: > > > CPU: 4 PID: 29 Comm: migration/4 Tainted: G S 5.8.0-rc4-00005-ge658591d66d1-dirty #158 > > > Hardware name: Foundation-v8A (DT) > > > pstate: 60000089 (nZCv daIf -PAN -UAO BTYPE=--) > > > pc : 0xbfff800010dadf3c > > > lr : __schedule+0x2b4/0x5a8 > > > sp : ffff800012043d70 > > > x29: ffff800012043d70 x28: 0080000000000000 > > > x27: ffff800011cbe000 x26: ffff00087ad37580 > > > x25: ffff00087ad37000 x24: ffff800010de7d50 > > > x23: ffff800011674018 x22: 0784800010dae2a8 > > > x21: ffff00087ad37000 x20: ffff00087acb8000 > > > x19: ffff00087f742100 x18: 0000000000000030 > > > x17: 0000000000000000 x16: 0000000000000000 > > > x15: ffff800011ac1000 x14: 00000000000001bd > > > x13: 0000000000000000 x12: 0000000000000000 > > > x11: 0000000000000000 x10: 71519a147ddfeb82 > > > x9 : 825d5ec0fb246314 x8 : ffff00087ad37dd8 > > > x7 : 0000000000000000 x6 : 00000000fffedb0e > > > x5 : 00000000ffffffff x4 : 0000000000000000 > > > x3 : 0000000000000028 x2 : ffff80086e11e000 > > > x1 : ffff00087ad37000 x0 : ffff00087acdc600 > > > Call trace: > > > 0xbfff800010dadf3c > > > schedule+0x78/0x110 > > > schedule_preempt_disabled+0x24/0x40 > > > __kthread_parkme+0x68/0xd0 > > > kthread+0x138/0x160 > > > ret_from_fork+0x10/0x34 > > > Code: bad PC value > > > > That's what FTR_EXACT gives us. The variation above is in the field at > > bit position 8 (API_SHIFT) with the boot CPU value of 4 and the > > secondary CPU of 1, if I read it correctly. > > Yes > > > Would it be better if the incompatible CPUs are just parked? I'm trying > > to figure out from the verify_local_cpu_caps() code whether that's > > possible. I don't fully understand why we don't trigger the "Detected > > conflict for capability" message instead. > > The above ptrauth crash appears when this fix patch is not present and > with this fix present, cpu4 is actually parked as, > > [ 0.098833] CPU features: CPU4: Detected conflict for capability 39 > (Address authentication (IMP DEF algorithm)), System: 1, CPU: 0 > [ 0.098833] CPU4: will not boot Ah, should have read the commit log properly. Thanks for the clarification. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel