Received: by 10.223.185.116 with SMTP id b49csp775912wrg; Fri, 23 Feb 2018 06:40:24 -0800 (PST) X-Google-Smtp-Source: AH8x2271XDbcPf2fp1VbSpI001rw1XG1RtDmz8sfj6XATqLvHvlfNaXUeYtDwo92qldBuDjc10mE X-Received: by 2002:a17:902:5269:: with SMTP id z96-v6mr1924633plh.385.1519396824716; Fri, 23 Feb 2018 06:40:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519396824; cv=none; d=google.com; s=arc-20160816; b=HkerCGpEvBY/VmcjO7AOhyNH76jllmJLfcKgkBXonRMN+w//JB2GOSjzPGP/RpMngX PV4eBM+qpWUwItv3iPsQkX7Z7z6qLZgsG9AOPUKZ7SPG9et/HVcodbJnRfgVv1mCjtC5 vK06Qc24hAT7Y5oZxoxT/DSUIo3Opahn7tP31eoSvs7Wnur/volalwIkPCl+JzAKPpTe jERpfTbxgAyi1OeZ5xJkYYd4Rtoz+TLitEVqnrOnBVH6eJWRzuUkunV3DhI6qqmNvPlV JMQdPRdlajFGAboyOd/QlwoQJfYV03F62lIiz7HIvEfgSh1co/Hd0NVKMDxXaQpOy5hs VAeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=FrG9RNPqrva3d17xeAe07v+mO3GoUjTh0f7SopVd93Q=; b=0gOdLSmDMViq0Yv7zYXCAt72kZeLJ/xxX5/6GkB/ckfOOeOfA03TRIFX/gxAGjsotZ sqRHLGFnkFLfYlhcpFYBfyzps18eg1RWr3lAHSTG6Z36qwmk/H5f7J/SCARX/FG9hXKk DoDpd5DnNkqD2UP4FBro0oWzRfisFy3osBQILtJe3hCvMadqqhHgsTu302Efp3nYnQAl sfhlODWgmxW00RNLF25UmlT9xwFv171oxjMOz6zM4I5/RsI7TFdl5ZEQJGkJTNoXrPNB uGFJSdgnGVk8cq3ZKaHxVtDWEStSYI8dV4Ou9MwcppSu18qqfb5QySbsLkBWtMqZewbQ 6CLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YhdosNHy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m25si1585069pgv.483.2018.02.23.06.40.09; Fri, 23 Feb 2018 06:40:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YhdosNHy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751551AbeBWOim (ORCPT + 99 others); Fri, 23 Feb 2018 09:38:42 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:37263 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751391AbeBWOik (ORCPT ); Fri, 23 Feb 2018 09:38:40 -0500 Received: by mail-it0-f65.google.com with SMTP id k79so470511ita.2 for ; Fri, 23 Feb 2018 06:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FrG9RNPqrva3d17xeAe07v+mO3GoUjTh0f7SopVd93Q=; b=YhdosNHytIpzNrTLN7ctWi7sePUvtnO+usXoqy7FBXkew321I9d2FdBDplBw859h/l oYkK3I13fajRY436FIWiiYSZtXAEe0mn6XPKVKTAaU8Qv7Wxpicfz7tmq4L/95oOEl+K /3t/Qifl5EVHlkJVDrz9iP25/FDdedOGw87YA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FrG9RNPqrva3d17xeAe07v+mO3GoUjTh0f7SopVd93Q=; b=l/eiP1gjFRduB5QpSYBI0L8YztEXJp8OXB5FRifCcdA8S0brOFOy1XvEnT/Jg8js5j 1RTj5p8vfnip0MsZWYTfws+b6pSJ1L0hOCvwVzk5rRO08MAPlM0Cql/4vlcViNnwM0HK 6z4qptbV9eLe5f1yd6xXYvE2Svf1AVta3XcrBu38JKySL6FRfqCckHmAp6k6alYXjqc/ Osu00wTjtpcSD8xQRMYwO/ZEsLBiwlmgX16UjwGz81ucHZM5iAJR9o1XHf/aghvDbCzX Tm7agjgUPMQMDxI1vTn7uztkAPuHtxLsswLk713G5Nbwlrj5rBDa7ZTBZbAGmur/s5x/ 1tYw== X-Gm-Message-State: APf1xPAFTH6LX4G5ghtu/gX5EL8rbPOPiNP2gok26X0ZAtMKVsL0Rkl9 QsL3ApU2VlD22lY/eDXsvNHK9dbwXpxOUXhnWcGx8yOoM1Q= X-Received: by 10.36.90.5 with SMTP id v5mr2540306ita.138.1519396719392; Fri, 23 Feb 2018 06:38:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Fri, 23 Feb 2018 06:38:38 -0800 (PST) In-Reply-To: References: <20180212113801.2552-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Fri, 23 Feb 2018 14:38:38 +0000 Message-ID: Subject: Re: [GIT PULL] arm64 spectre and meltdown mitigations for v4.14-stable To: Nicolas Dechesne Cc: Greg Kroah-Hartman , stable@vger.kernel.org, lkml , Will Deacon , Catalin Marinas , Marc Zyngier , Mark Brown , linux-arm-kernel , Bjorn Andersson , Srinivas Kandagatla , Andy Gross Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23 February 2018 at 14:19, Nicolas Dechesne wrote: > hi, > > On Mon, Feb 12, 2018 at 12:38 PM, Ard Biesheuvel > wrote: >> Hi Greg, >> >> As mentioned by Will, I have created the v4.14 counterpart of his stable >> backport of the arm64/ARM Spectre/Meltdown mitigations that have been pulled >> into v4.16-rc1. >> >> Given that this is the v4.15 version backported to v4.14, I have removed any >> mention of 'conflicts' from the commit logs as they are now ambiguous. The >> patches applied surprisingly cleanly, I only needed to drop two patches that >> are already in (the same ones Will mentioned in his PR), and drop another one >> dealing with SPE, support for which did not exist yet in v4.14. I also included >> the patch >> >> arm64: move TASK_* definitions to >> >> from v4.15 to make Robin's Spectre v1 patches apply more cleanly. >> >> Thanks, >> Ard. >> >> Will Deacon (40): >> [Variant 3/Meltdown] arm64: mm: Use non-global mappings for kernel space >> [Variant 3/Meltdown] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN >> [Variant 3/Meltdown] arm64: mm: Move ASID from TTBR0 to TTBR1 >> [Variant 3/Meltdown] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 >> [Variant 3/Meltdown] arm64: mm: Rename post_ttbr0_update_workaround >> [Variant 3/Meltdown] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN >> [Variant 3/Meltdown] arm64: mm: Allocate ASIDs in pairs >> [Variant 3/Meltdown] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper >> [Variant 3/Meltdown] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI >> [Variant 3/Meltdown] arm64: entry: Add exception trampoline page for exceptions from EL0 >> [Variant 3/Meltdown] arm64: mm: Map entry trampoline into trampoline and kernel page tables >> [Variant 3/Meltdown] arm64: entry: Explicitly pass exception level to kernel_ventry macro >> [Variant 3/Meltdown] arm64: entry: Hook up entry trampoline to exception vectors >> [Variant 3/Meltdown] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code >> [Variant 3/Meltdown] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks >> [Variant 3/Meltdown] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 >> [Variant 3/Meltdown] arm64: kaslr: Put kernel vectors address in separate data page >> [Variant 3/Meltdown] arm64: use RET instruction for exiting the trampoline >> [Variant 3/Meltdown] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 >> [Variant 3/Meltdown] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry >> [Variant 3/Meltdown] arm64: Take into account ID_AA64PFR0_EL1.CSV3 >> [Variant 3/Meltdown] arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR >> [Variant 3/Meltdown] arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() > > we are seeing a regression on Qualcomm Dragonbooard 410c at this > commit ^. we are seeing the same regression on 4.15.x, where the same > commit exists too. However there is no regression on mainline. > > Starting from this commit , this is the bootlog (with earlyprintk) > ... > [ 0.239866] alternatives: patching kernel code > [ 0.244070] ------------[ cut here ]------------ > [ 0.248350] kernel BUG at ../arch/arm64/mm/mmu.c:138! > [ 0.253128] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > [ 0.258073] Modules linked in: > [ 0.263455] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.3 #27 > [ 0.266495] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) > [ 0.272662] pstate: 00000005 (nzcv daif -PAN -UAO) > [ 0.279347] pc : __create_pgd_mapping+0x544/0x660 > [ 0.283943] lr : __create_pgd_mapping+0x4d0/0x660 > [ 0.288714] sp : ffff000008033cb0 > [ 0.293400] x29: ffff000008033cb0 x28: ffff800000e2ffff > [ 0.296701] x27: ffff800000080000 x26: ffff800000200000 > [ 0.302083] x25: 0000000080080000 x24: ffff800000e30000 > [ 0.307379] x23: ffff7dfffe638000 x22: 00000000bfef6003 > [ 0.312673] x21: ffff800000080000 x20: 00e0000000000f93 > [ 0.317969] x19: ffff800000e30000 x18: 0000000000000010 > [ 0.323264] x17: 000000001f8013fb x16: 000000000522cdac > [ 0.328558] x15: 0000000000000000 x14: 0000000000000400 > [ 0.333854] x13: 0000800080000000 x12: 0000000080080000 > [ 0.339150] x11: 00e8000000000f13 x10: ffff8000001fffff > [ 0.344445] x9 : ffff800000080000 x8 : 00e0000000000f93 > [ 0.349739] x7 : ffff800000090000 x6 : 0040000000000041 > [ 0.355034] x5 : 0040000000000001 x4 : 00e8000080080f93 > [ 0.360329] x3 : ffff800000080000 x2 : ffff7dfffe639400 > [ 0.365624] x1 : ffd7ffffffffff7f x0 : 0008000000000880 > [ 0.370922] Process swapper/0 (pid: 1, stack limit = 0x0000000095a442e7) > [ 0.376216] Call trace: > [ 0.382899] __create_pgd_mapping+0x544/0x660 > [ 0.385070] update_mapping_prot+0x48/0xd8 > [ 0.389585] mark_linear_text_alias_ro+0x68/0x8c > [ 0.393579] smp_cpus_done+0x60/0x9c > [ 0.398351] smp_init+0xfc/0x114 > [ 0.401909] kernel_init_freeable+0xcc/0x224 > [ 0.405123] kernel_init+0x10/0x100 > [ 0.409374] ret_from_fork+0x10/0x18 > [ 0.412588] Code: 92801001 f2fffae1 ea01001f 54000040 (d4210000) > [ 0.416420] ---[ end trace e7ed67ae05b55982 ]--- > [ 0.422430] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0000000b > [ 0.422430] > [ 0.427091] SMP: stopping secondary CPUs > [ 0.436203] ---[ end Kernel panic - not syncing: Attempted to kill > init! exitcode=0x0000000b > [ 0.436203] > > I understand this is not a lot of data. but I am a bit clueless here. > One thing worth saying is that we are using custom/proprietary > firmware here, and CPUs are started in EL1. The DB410c is based on > APQ8016 SoC from Qualcomm (4x Cortex A53). OK, so it seems like mark_linear_text_alias_ro() may be putting down global mappings again. Could you please try with the below folded in please? diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index fa20124c19d5..36282fc05665 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -140,8 +140,13 @@ static void init_pte(pmd_t *pmd, unsigned long addr, unsigned long end, * only allow updates to the permission attributes. */ BUG_ON(!pgattr_change_is_safe(pte_val(old_pte), pte_val(*pte))); + if (!pgattr_change_is_safe(pte_val(old_pte), pte_val(*pte))) + pr_warn("%llx %llx %llx %llx\n", PAGE_KERNEL_RO, + pte_val(old_pte), pte_val(*pte), + pte_val(old_pte) ^ pte_val(*pte)); phys += PAGE_SIZE; } while (pte++, addr += PAGE_SIZE, addr != end);