Received: by 10.223.176.46 with SMTP id f43csp515419wra; Fri, 19 Jan 2018 22:58:35 -0800 (PST) X-Google-Smtp-Source: AH8x224vj4bUiDhVNWT30JI/mO+DUqGDMC6BqHapC60sdEjlmN0phTZG7y3kkbcWcdxsuAievHdS X-Received: by 2002:a17:902:24a2:: with SMTP id w31-v6mr526516pla.257.1516431515318; Fri, 19 Jan 2018 22:58:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516431515; cv=none; d=google.com; s=arc-20160816; b=H7xSy45aV5Nn58ettPjzwy1ORKS+QQLl8unp5qLrvMoXCIHtozpsCI1jIW20A3tMcW PpwpoAislr6VqVrH38Q3/eDxfczLaZPtkgpVqfdT/VvMLaTFG/PyGhX9ZPy18BCfOamt sbNPHXqvbuIXi9ZAF9+4wjUsy5sZUAOAvuG6t6I0p1c2kIspxMGyZt8KWGDk3ALCtGkF vyQgRhHKWwVLaUqgYmkZwZ0UATRyskDQNySCK49Yom26KfhA8UzXUpNOctJ5r2KanjYc Ex32Cyu2vDGEQ2Ol9wTAnyiYKt1hQVDt6gjIy9sXh0Wo+5noLlUsCBze4eF4f1tOv5D4 eQoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=IdeajyKkMs520sOrCnRTwEMVX2WDCoF6JAI9gXFoNoI=; b=hgK1fF2skNNcpE4E1r5ucnjf9ySTDljdgf8WHg9rFlv6GhqGsA/ELfzfV6itI5BkpS BfKbytIsfUqwx4cPg8FYjIbGz3iYBBdORv6g+wfg+ZhncQwB0bTEHtkLhMOqz0xO01ol EOfoHUlIFnnT+KCjyIonZw8SwUv70tKwyebsP4LuLLS60gGcEjKEdc5z8V1z26SDXgjo 0LkhVi+Omyv5VdJ7kabm+0l71t6GOrE1vb/I4GklAbMvon9GWiHxhd0UEfZyjDCDkFZg tAnJ4FJ1bGpg93yzXEplCL8w2reRXwt1sFSOOc+VBVNZKU1KAb8hXwFh+UDrWuwIsOyb utoA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j14si2103174pgf.585.2018.01.19.22.58.21; Fri, 19 Jan 2018 22:58:35 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753416AbeATG5Z (ORCPT + 99 others); Sat, 20 Jan 2018 01:57:25 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:44950 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbeATG5U (ORCPT ); Sat, 20 Jan 2018 01:57:20 -0500 Received: by mail-pf0-f169.google.com with SMTP id m26so3052615pfj.11 for ; Fri, 19 Jan 2018 22:57:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IdeajyKkMs520sOrCnRTwEMVX2WDCoF6JAI9gXFoNoI=; b=dacNfZApOhqzeLSDkfuibmUALP/rQCSpdk4DrIu/wBRaOz+NS81c6ub0fYd6ucAf0U 51dRn62/sEMOQXKuuJKtGb2280miojOAavjGtUysIZswDP0qHoFRNMf+ebQe7o4Hwbv5 JDad06+uoZmMUYYzD/JJELp5PJd67PoNFbjjbDMFmKTxpSjrbDD5/97z0roL6/e21hW2 vjcDPRthqLsJU7fQdyiiMZwLTG6Sh5TYkvN9MWYFTutE8n/yRkDuXHxGMC8PA6StTBJQ f7aT+4muVVt1wJxDMrSGtc8TcDj5xG+bHhfcaMtCGYrYDEAymR7TdDXgF2Cbfqk0iFj2 b9qQ== X-Gm-Message-State: AKwxytcV1wPOUQrbqiR1lJTKqrAYrz6TKryELacIIfkS8heLOsUwOpc6 f+upHyA9wB4mSI3ovrh3JVGz9snf62s= X-Received: by 10.99.53.14 with SMTP id c14mr1094506pga.321.1516431439597; Fri, 19 Jan 2018 22:57:19 -0800 (PST) Received: from localhost.localdomain ([2601:602:9802:a8dc::61c1]) by smtp.gmail.com with ESMTPSA id j4sm10143235pfe.53.2018.01.19.22.57.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 22:57:18 -0800 (PST) Subject: Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8 To: Tom Lendacky , Gabriel C Cc: Borislav Petkov , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Brijesh Singh , X86 ML , Linux Kernel Mailing List References: <9fdddcb1-d122-7d52-9204-7066ada5ccba@redhat.com> <44505ab1-237b-88ea-1fb1-f80de9b3025a@redhat.com> <6277b77a-d4a0-5669-e5aa-7a850436227c@amd.com> From: Laura Abbott Message-ID: <6b616ebc-1a8f-0bd7-68be-3674ff99500b@redhat.com> Date: Fri, 19 Jan 2018 22:57:17 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <6277b77a-d4a0-5669-e5aa-7a850436227c@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/2018 10:15 PM, Tom Lendacky wrote: > On 1/19/2018 11:25 PM, Gabriel C wrote: >> 2018-01-20 5:02 GMT+01:00 Laura Abbott : >>> On 01/19/2018 06:23 PM, Gabriel C wrote: >>>> >>>> 2018-01-20 2:23 GMT+01:00 Laura Abbott : >>>>> >>>>> Hi, >>>> >>>> >>>> Hi , >>>> >>>>> >>>>> Fedora got multiple reports of an early bootup crash post -rc8. >>>>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce >>>>> parameters for SME PGD mapping") . It doesn't revert cleanly >>>>> but if I revert the few other changes in arch/x86/mm/mem_encrypt.c >>>>> as well it boots up fine. >>>>> >>>>> Annoyingly, I can't seem to get any actual kernel logs even with >>>>> earlyprintk. It just reboots immediately (triple fault?). This >>>>> happens on both of my Lenovo machines and I can ask other reporters >>>>> for details as well. >>>>> >>>> >>>> I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs >>>> on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box , >>>> on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs >>>> disabled. >>>> >>>> Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on >>>> current master/rc8++ without to see something like this. >>>> >>>> Also we pushed these patches on 4.14.13/14 and didn't got any reports >>>> about >>>> something like this. >>>> >>>> What Lenovo boxes are these ? maybe I find one to reproduce. >>>> >>>> >>>>> $ git bisect log >>>>> # bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag >>>>> 'trace-v4.15-rc4-3' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace >>>>> # good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8 >>>>> git bisect start 'origin/master' 'v4.15-rc8' >>>>> # bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag >>>>> 'mmc-v4.15-rc2-3' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc >>>>> git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68 >>>>> # good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag >>>>> 'mac80211-for-davem-2018-01-15' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 >>>>> git bisect good 161f72ed6dbe7fb176585091d3b797125d310399 >>>>> # good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch >>>>> 'x86-pti-for-linus' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>>> git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c >>>>> # bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm: >>>>> Prevent >>>>> use after free >>>>> git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702 >>>>> # good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic: >>>>> Remove >>>>> init_bsp_APIC()" >>>>> git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf >>>>> # bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to >>>>> reduce parameters for SME PGD mapping >>>>> git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4 >>>>> # good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up >>>>> register >>>>> saving in the __enc_copy() assembly code >>>>> git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99 >>>>> # first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: >>>>> Use a >>>>> struct to reduce parameters for SME PGD mapping >>>>> >>>>> >>>>> Configuration is at >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide >>>>> Note that I do think this is something in the Fedora configuration >>>>> because a generic "make defconfig" booted just fine. >>>> >>>> >>>> But maybe some of the Fedora patches ? >>>> >>>> Can you try an kernel with the config but without any patches ? >>>> Or a defconfig and just enable CONFIG_AMD_MEM_ENCRYPT ? >>>> >>> >>> The bisect was a vanilla kernel without Fedora patches. >> >> Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD >> Workstation ( EPYC CPU ) > > I've tried multiple config combinations on my EPYC system and have not > been able to reproduce this issue and have not had any boot issues with > mem_encrypt=on or mem_encrypt=off. I don't have access to a non-AMD box > at the moment, but I'm really scratching my head on this one. > >> with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) .. >> I disabled Selinux since I don't use it here and module signing. >> >> Also with your config my serial setup won't work and the kernel hangs >> but mem_encrypt=on/off works just fine. > > If your using the EPYC serial device and you haven't enabled legacy > serial device support (if your BIOS supports that), then you're using > it as a platform device. The fedora config has not set the > CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module > to load and give you serial output. > > I'm confused when you say the kernel hangs but mem_encrypt=on/off works > just fine, can you explain that a bit more? > >> >> Also I notice on the Workstation it takes forever to boot untill >> 'DMA-API' reports out-of-memory >> ( dunno how much memory it need but the box has 128GB of RAM ).. > The machines I have are a Lenovo X1 Carbon and a Lenovo T470s. A Lenovo X220 ThinkPad also reported the problem. If I comment out sme_encrypt_kernel it boots: diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 7ba5d819ebe3..443ef5d3f1fa 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -158,7 +158,7 @@ unsigned long __head __startup_64(unsigned long physaddr, *p += load_delta - sme_get_me_mask(); /* Encrypt the kernel and related (if SME is active) */ - sme_encrypt_kernel(bp); + //sme_encrypt_kernel(bp); /* * Return the SME encryption mask (if SME is active) to be used as a Interestingly, I tried to print the values in sme_active (sme_me_mask , sev_enabled) followed by a return at the very start of sme_encrypt_kernel and that rebooted as well, vs booting if I just kept the return. sme_me_mask and sev_enabled are explicitly marked as being in .data, is it possible they are ending up in a section that isn't yet mapped or did I hit print too early? Thanks, Laura