Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4390104imm; Tue, 11 Sep 2018 11:06:25 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYTVfyXTAnjP9TbnKReFPi4XnpG35sc+ueNIW/DmauozJsaJnIXSACsukPNlyNkjnStQ+43 X-Received: by 2002:a62:c90a:: with SMTP id k10-v6mr30777082pfg.180.1536689185584; Tue, 11 Sep 2018 11:06:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536689185; cv=none; d=google.com; s=arc-20160816; b=kvR/FBXsahF52ycFQ7jwgzbQRKsG513cyYNQP2TEUAQc556qIC/vcBHQOf/xmfIa+1 yuCtDB8hD2v9du9SQvNmF5UUcD6cwW7SZFKxE25UOv4dcd035mOMfRIn89X+YwrUNoyS xT17apgtjj0iQZQXed/PKB329FEZF5tCav00+yDuTOO1VeyGCupeezPd1YA0Kry3ydkd zNoF4SxWRGo3G2WqPZ2DCdw9iBM9sRV5sQ/lyTDd31Gl42KyrYoB4VfkCHse+uKqhMdj 81TaBgTCF9cNOk0TXv91+puADeuCeRS3WzztP4Qp2wqc33tIY5zqwI00siBev2fDCUC8 TDIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=8om5IPMIir/i0mRgWtf51A5W7VMLQm0+ityiOvXunpg=; b=e7OSCSDM8VgFpxqxTfB4NAdMSTuvCed1TCl7br0ZZS1sew+kQxcYR3TopZo2vkcykL Ble3FuY8MEiL6flLMmEMGPvuJDiWTijXUcOitVwZXdlp8M8REwCH+f6me9v+/DyPM31e u8Zxi8tXleJILPTqcN4Ngz+emURM42j46489CohYcITkk8KWNdfeNLAFrEGK7rUdFW+S xdS0jDQWmReh1V9/CMt5XMBAP/YRc499YkBKcnMMap2if5Kza5/UUulnjr/L+gEq6A2t 0BopXylmlXBd7pLUSmZehserJNjVYX95GWeTsp+r+PbrshDDCd92jINin/Bntt691yb6 BR0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="p4qx5UU/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x37-v6si22949835pgl.544.2018.09.11.11.05.56; Tue, 11 Sep 2018 11:06:25 -0700 (PDT) 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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="p4qx5UU/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727715AbeIKXF4 (ORCPT + 99 others); Tue, 11 Sep 2018 19:05:56 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:43075 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726689AbeIKXFz (ORCPT ); Tue, 11 Sep 2018 19:05:55 -0400 Received: by mail-pg1-f193.google.com with SMTP id v66-v6so12631241pgb.10 for ; Tue, 11 Sep 2018 11:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8om5IPMIir/i0mRgWtf51A5W7VMLQm0+ityiOvXunpg=; b=p4qx5UU/5KnFW3M0/xpxAWu+IOvSfE8aTvS1OTT3ED2CRM7R0QwzjQ2tKxAsoEGlUA vOMiPjRHYXtSPdm9evuF/qKlAq42jG5FMM/4DuaPX2DcBPm781S4FtphFsu8UdQ6rh2m m+u2J3d1kbQQNtjtvH6Eyeo3j/LVyGzhxxHViUM4jjk9g0kSGsn02W4esGpWUgIZV1K5 SFx5be5dJjW/5FfRUvIpc0rv+2NzKTSO4KvoAzaLhvBPKNnE8x4u6FXH55fLbLLB8PYD xo/mMFjmId724ReZO/nJ6cLw2C2A0vD/GhQ55zb4VN4QKBoAzM9i/w7/wiHWuAhy/6XI DexA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8om5IPMIir/i0mRgWtf51A5W7VMLQm0+ityiOvXunpg=; b=DF6NYH25AAW0wWkkWqs9/ia/h7AuZS01XQStRdhNzaGs3qaobmiRY3bvLkGr2cEJBi gxra+1h/j+g5KCgc5MT5aowYaG3lWKoibSOEmXLJieVVtzkKdqHTZ4i3bQTfwhvOl5jl MhsnWBDMmw2dWXCGb0sgTJV18MWAlb6SFqhQmhPRr2VjxbOHjFNGgaBmjwHp4SOwtNi+ 9ulCDS8Pjmm/mr3myKcwAvgj1BEEmZqMLq1iF2y01ETHviFWCthk4YHpBZQh+IhtIVlF wSctMmjC0taLmSYZ2nNJoGMwZ8Un7T4yHuGrYMjdRYH7N+gofyqrR/36+cmg/GD+NIkR R94w== X-Gm-Message-State: APzg51Cbq2JAnv10Pn4A5RPpdqbgdCa1id4D61cTh+LIZznrhdQXFENM 9ZlMeydpIT6F6dHG3TQRWXsSDw== X-Received: by 2002:a62:f555:: with SMTP id n82-v6mr30552387pfh.59.1536689128361; Tue, 11 Sep 2018 11:05:28 -0700 (PDT) Received: from [100.125.110.147] ([104.129.198.50]) by smtp.gmail.com with ESMTPSA id t12-v6sm23815911pgg.72.2018.09.11.11.05.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:05:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Random crashes with i386 and efi boots From: Andy Lutomirski X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180911174158.7qu6f4vfnfzqqrcf@suse.de> Date: Tue, 11 Sep 2018 11:05:25 -0700 Cc: Guenter Roeck , linux-kernel@vger.kernel.org, Ard Biesheuvel , Thomas Gleixner , Michal Hocko , Andi Kleen , Linus Torvalds , Dave Hansen , Pavel Machek , linux-efi@vger.kernel.org, x86@kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <51FDF5AF-2FE8-4817-9A5C-8CE4A8BC23AB@amacapital.net> References: <20180910215659.GA17966@roeck-us.net> <877118e5-beee-4551-28d3-79e7aa52f74e@roeck-us.net> <90A7FF2E-F186-49CF-A028-CDE317BE13E1@amacapital.net> <20180911174158.7qu6f4vfnfzqqrcf@suse.de> To: Joerg Roedel Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sep 11, 2018, at 10:41 AM, Joerg Roedel wrote: >=20 > On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote: >>> save_pgd =3D efi_call_phys_prolog(); >>> local_irq_save(flags); >>> status =3D efi_call_phys(...); >>> local_irq_restore(flags); >>>=20 >>> efi_call_phys_epilog(save_pgd); >>>=20 >>> So, yes, interrupts are very much enabled. >>=20 >> Does fixing that solve the problem? It seems more robust. >=20 > The problem is still that in efi_call_phys_prolog() we load the gdt with > its physical address, and when we reload the %cr3 in _epilog from > initial_page_table to swapper_pg_dir again the gdt is no longer mapped. > Blocking interrupts is more robust, but we can't block NMIs that way > that would also trigger the issue, no? >=20 > So I am in favor of changing the order in efi_call_phys_epilog() too. >=20 I=E2=80=99m rather confused here. We=E2=80=99re loading CR3 with page table= s that don=E2=80=99t have the fixmap mapped? With interrupts on? And we ex= pect it to work? This is *nuts*. There are IMO only three sane fixes here: 1. Load the fixmap, cpu_entry_area, etc into the EFI page table. Drop the G= DT reload entirely. 2. Do this whole virtual map dance earlier so we don=E2=80=99t have IRQs and= NMIs and such. Maybe while we=E2=80=99re still using the initial page table= ? 3. Just identity map all the EFI regions. Make EFI page tables that literall= y map them at their physical addresses *and* map the entire kernel, just lik= e we do for normal user mms. Sure, as a stopgap, turning off IRQs and applying Guenter=E2=80=99s patch se= ems okay, but this code is not okay.=