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,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_GIT 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 06B93C433E0 for ; Tue, 26 Jan 2021 16:05:31 +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 B6D3E207B3 for ; Tue, 26 Jan 2021 16:05:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6D3E207B3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.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:MIME-Version:References:In-Reply-To:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/DKBLxnfeiMPKaDEiJDjbdUER3RNDi/JrO6GQhJjVN8=; b=EPa6fo52pNKMrAFQmKanc8p7t sYonNsX1SpJBPGz+NcCYkAiWMD4UMr2Y85gb8bmvA3kszBz286hT+zZufwxadi/8qFZOJqSQuWTUo zSzh9CdG6ZMGraqq8LSlBZdVNUIj1bL9He0MeGYXU8fhfT31MQWHT0y9TzMhGqtmY27NUFM3yl5Q7 DIaFiI/bJ27epa4Na9FjD4KLLZ/dQ3AqH8wqPbi3fR2Iir+8pZgRxf2FF3D9DJiP8t+EOVhFpFTcT m99Bw0/MCyo8RMi27T3ArtxFtI85bgASQWLUnIKeEdFNfB2jjcaVOjQmHjb0vqjQc/+eK9rwZpy71 fh0viCfWA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4QoP-00085V-Rl; Tue, 26 Jan 2021 16:03:25 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4QoL-00084l-En for linux-arm-kernel@lists.infradead.org; Tue, 26 Jan 2021 16:03:23 +0000 X-UUID: 57cfbf55daa4407ab87d984bd6529313-20210126 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=NRuLwjABkevbzktT50g9fVMGw3X4yPhgUSVN0qa8Flo=; b=TZolQ1BDfwfKLMR7dSUXOWjQ6hVeckTCRmsJAPE53IgDHX1qKiBZ2ZGPEfI5W8UZvz5/N6b4NmOAdd6vJv2pTaRVt8znq+lpuhilHKse7Gz1Azzs5WXLi2/w/+2++o7gYK7VRRO9VDFRkdmOt6wiShxDKryKZ5wQ7vPs+VyJEiQ=; X-UUID: 57cfbf55daa4407ab87d984bd6529313-20210126 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 418681440; Tue, 26 Jan 2021 08:03:16 -0800 Received: from mtkmbs05n1.mediatek.inc (172.21.101.15) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 Jan 2021 08:03:14 -0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs05n1.mediatek.inc (172.21.101.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Jan 2021 00:03:13 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 27 Jan 2021 00:03:13 +0800 From: Lecopzer Chen To: Subject: Re: [PATCH] ARM: mm: harden branch predictor before opening interrupts during fault Date: Wed, 27 Jan 2021 00:03:03 +0800 Message-ID: <20210126160303.16157-1-lecopzer.chen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20210126152916.GJ1551@shell.armlinux.org.uk> References: <20210126152916.GJ1551@shell.armlinux.org.uk> MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210126_110322_240841_6190CF5E X-CRM114-Status: GOOD ( 32.44 ) 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: lecopzer.chen@mediatek.com, marc.zyngier@arm.com, gregkh@linuxfoundation.org, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, peterx@redhat.com, yj.chiang@mediatek.com, rppt@kernel.org, akpm@linux-foundation.org, walken@google.com, tglx@linutronix.de, 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 Tue, Jan 26, 2021 at 11:01:50PM +0800, Lecopzer Chen wrote: > > > On 2021-01-26 10:59:32 [+0000], Russell King - ARM Linux admin wrote: > > > > On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote: > > > > > Hi all, > > > > > > > > > > I don't see any fix for this issue now(maybe I missed it..?), > > > > > could we fix this if there is better solution? > > > > > This issue exists almost two years. > > > > > > > > I don't think anyone provided an acceptable patch. > > > > > > > > The first patch moved the hardening out of the translation/section > > > > fault handling. Since the kernel is mapped with sections, these > > > > are above TASK_SIZE, and the whole point of the branch prediction > > > > hardening is to prevent the prediction in the kernel being exploited, > > > > missing the hardening effectively makes the mitigation useless. > > > > > > > > The discussion in February 2019 never concluded from what I can see. > > > > > > My memory is that I never got a reply which I understood. > > > Let me try again this week with the information above. > > > > > > NOTE: > > Before sending this mail, I had searched the relative threads and > > there are two solutions in general: > > 1. Add get_pcpu()/put_cpu() https://lkml.org/lkml/2019/6/3/426 > > Reject by Marc: > > > The right fix would be to move the call to a point where we haven't > > > enabled preemption yet. > > > > 2. Move out like the patch from Sebastian: > > This seems follow the concept of 1. > > (move the call to a point where we haven't enabled preemption yet). > > But I can't find any reply in the thread. > > > > Now the CONFIG_HARDEN_BRANCH_PREDICTOR has already backported to LTS, > > and after upgrading ARM CONFIG_CPU_V7 products to latest LTS, the > > CONFIG_HARDEN_BRANCH_PREDICTOR will be default y and this issue makes > > our devices panic and we have to either disable HARDEN_BRANCH_PREDICTOR > > or hack in-house to avoid the kernel panic. > > It does _not_ cause the kernel to panic, ever. A kernel panic takes > out the system. This is not the case here. > > It merely causes a noisy message to be emitted in the kernel log, and > the system survives. That is way more preferable than breaking the > effect of branch predictor hardening. > > If it is taking out your kernel with a real panic, then there is > something wrong elsewhere - and this is _not_ something that should > be happening during normal system operation. Oh, yes, you're right; After reread the panic log, our panic happened because -> invalid userspace memory access -> debug_preempt log -> the program seg fault -> main service need the program but it crash -> panic Sorry for wrong information and thanks a lot for the correctness. I think I have to see why the in-house hacking is working... Thanks!! BRs, Lecopzer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel