Received: by 10.223.176.46 with SMTP id f43csp520796wra; Fri, 19 Jan 2018 23:05:12 -0800 (PST) X-Google-Smtp-Source: AH8x224q4zB0HUzyiOfhV3qSs8IVAWWczeqmqr+YxhwUO/ecusTZk8G4i1lqzl6mEuFxHFt4A8oO X-Received: by 10.101.92.129 with SMTP id a1mr1151699pgt.198.1516431912698; Fri, 19 Jan 2018 23:05:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516431912; cv=none; d=google.com; s=arc-20160816; b=W26M+4U2Bpy6H3r27Lh0GBPHqx/dgrnOpC6DSZ9DFHc213UoCkiLiXErTbqXtY3wW4 VipK6ZrR4Bpt7jjgQ0uUedgZ8Ht0U9WD9iMMf3L6PtUoNAWanyaV2lYiyaMZLAftaJOA wgHnifU3+fX3DlmsDGupLaqhTyH2KTzuhavalrZWymYhfHfUCaWCLnOQR2SniGV1neZ3 68jcCf2NkqkAeaKr7zjZDh8PeXerJUmkJ+iP6YvwVQ3ObYNJzPCQ0+1jxNz0tSFm3SdT glugjeKnn8h+sRqzjhu5fIOPIkBPz0GXoem2QWUpzZO73V07oEXw3RMCQ3gUTibmZIRM pZdw== 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:references:cc:to:from:subject:arc-authentication-results; bh=jFaugKi4dTAVLESaMU9KaIlWdO9q2yr1uYSbzUvgZxE=; b=Z8PD28KQLo9xzLneodELaYGd64Nz1TevaTJH8AczJNlkaSKqrAEPmlfF3NMk8ngOKS MD2Eu4ylA6py0g9sYqIOq/dM8/QJNj3UyRQilsKK2RjhJaUc6eM1AA+zioaF7ed256Ra 2VIjTc1J2mGmz6//O/FHNvj0TBmVMRyIiBu1dWIeJ954LMA9JSF7+Cu4z/ye2sWMLPmV 8lZzfdq4n9sUwOqjV+uPTBX3GmDTpo75lfm4L23EpsKoLEyJlX4BeJsP3R0tZaOKV4tj vKJ4dLAtqhBqFx1ggFP763LJwXe2WjJt1G10Hryq/B7Ahr8AUIw5xNoLNkXvblhbuzcp rN9Q== 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 f68si10757740pfb.203.2018.01.19.23.04.58; Fri, 19 Jan 2018 23:05:12 -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 S1753416AbeATHDi (ORCPT + 99 others); Sat, 20 Jan 2018 02:03:38 -0500 Received: from mail-pf0-f178.google.com ([209.85.192.178]:33099 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbeATHDa (ORCPT ); Sat, 20 Jan 2018 02:03:30 -0500 Received: by mail-pf0-f178.google.com with SMTP id t5so3071020pfi.0 for ; Fri, 19 Jan 2018 23:03:30 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jFaugKi4dTAVLESaMU9KaIlWdO9q2yr1uYSbzUvgZxE=; b=hBeh/b64z+YFdLKvBzQsXsl9P3OuRFZfr6R/Wrci1I9bY2mSAAxWjzHw5NzGj9v59h /TIbRcor/DzsyoGdLRz5MHKGG5LwyTEwMEfWsPrXKFpGkWYSKN1bMzjMQkpPNDmA0E8s Am37blmJ0C9cWsnMFaw/AKxONxUcq7exObQ2Zh9YWaLC5kRQfNCf9XzJx3S64opzvzrb 2FgBr4tFOwg+3aT/1MZrf+TtyvdabhVtHdngpaP6LlNJX3t8nH9PLqgjHLS/GU57r6aZ c0uJqq4dA2Sj0sXNhZJBjS8iFkHljhVRdikmgxqMr+po3i0QBUXBFcUBGx6nmpG/S++Y i+lg== X-Gm-Message-State: AKwxytcFCI+h91XKXXJvycV9XpKVNLyFGoUpEnmjAd6yxlhyYMyHsxQc jhJ3XSp3o/rgyob//ZZ6c+xTdJ1gBro= X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr521674plz.385.1516431809654; Fri, 19 Jan 2018 23:03:29 -0800 (PST) Received: from localhost.localdomain ([2601:602:9802:a8dc::61c1]) by smtp.gmail.com with ESMTPSA id z186sm19662739pgb.70.2018.01.19.23.03.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 23:03:28 -0800 (PST) Subject: Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8 From: Laura Abbott 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> <6b616ebc-1a8f-0bd7-68be-3674ff99500b@redhat.com> Message-ID: <2cf1f64f-b7df-9f3a-ce61-36cd4fe5688b@redhat.com> Date: Fri, 19 Jan 2018 23:03:27 -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: <6b616ebc-1a8f-0bd7-68be-3674ff99500b@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/2018 10:57 PM, Laura Abbott wrote: > 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 > One last note: This was built with gcc 7.2.1