From owner-freebsd-current@freebsd.org Fri Mar 23 23:06:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 604CBF53E23 for ; Fri, 23 Mar 2018 23:06:25 +0000 (UTC) (envelope-from mark@peek.org) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF38569FB2 for ; Fri, 23 Mar 2018 23:06:24 +0000 (UTC) (envelope-from mark@peek.org) Received: by mail-yb0-x244.google.com with SMTP id o197-v6so3315478ybg.5 for ; Fri, 23 Mar 2018 16:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peek-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kpMqnDcrFBRkrhtq8uLHDx2cZI61/5HE0eQCKBW8C3g=; b=mZ/OYyCNtq+q4eUS653L16UpCToHOzi5Y1gM8J4GM2RCBRWhquc4fu9YB6SjQGvWA/ twnjeiGMwQaUUuePU/EnP9xRgIohZF1Sc7PbaqhaAWUmKSbJ6LjJ2JK+hLStDECjPz/y g0lnWaqHUs01hSbjTiz+z+twZDsS9qe4ldBa0u1JSs/JnmeaYa0nwd61NDOOaa0BfDA4 WhUT6ekpGdFP7q5T4RYabD9u1Fc7Sped9mh2zPwZ88CNHoJqO3taKFxv+G3l30saFzEX Sv/wvpI9oirMpmXw6nfoNnCSyIrw95hQrlenNsUDN9gSlokpDhFqWbOdDD4iBu6WjFOV kadg== 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=kpMqnDcrFBRkrhtq8uLHDx2cZI61/5HE0eQCKBW8C3g=; b=aTgoiItPm9btTim//0crAf/r0st2s7/IFnWrjhX/rVrybaFiPjF/ZDlug9qhyhVrLW 0q/7OJwYoZYXsuL4ZSskQ1SUzTGN/900aQvk+zYlicbREd2rlQxzJQJrHfOyh3DWrWhy rP7niYAeSwwQR3t360qfPJrrZvIzDc8Py9JLoGnBg4PsMcSpXwZL8qeKqAtaWIhogImm iWzJyCDhNuELOBL9G+EppeCXazCK/vC0r7FDgInw4gdZm1ArY9aomn6IuPnk4QwJb/n/ TASexjm3JKoNz8wmIVkiJhT2Sew1Yoz7eKE4h6ngAqjNIQjY3XW4XKoE4gyD2phb/YID IJBg== X-Gm-Message-State: AElRT7EbUv2VGKcmlu7ffLVVraLmSR+GvJHSv10v4y7htXJQp/12zXDA UICwZhm+if5Fo0ij9EgK1g5snMG4PEXkL9jC5uDUyA== X-Google-Smtp-Source: AG47ELvFLesj28kHM1PNN4F8sojOLulyvxdCPZYWkibPZ8MU3x0LSxUVwRVK5vZ9C/e+Ll1Y/4Bm5P66ByCvMbgNXCU= X-Received: by 2002:a25:5e41:: with SMTP id s62-v6mr18190314ybb.115.1521846384084; Fri, 23 Mar 2018 16:06:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:1057:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 16:06:23 -0700 (PDT) X-Originating-IP: [2601:646:c700:35ed:b42e:d398:1bb6:3336] In-Reply-To: <20180316095627.GW76926@kib.kiev.ua> References: <8b8f1352-aa5c-716c-ef6c-3b3cd630043f@ieee.org> <20180316095627.GW76926@kib.kiev.ua> From: Mark Peek Date: Fri, 23 Mar 2018 16:06:23 -0700 Message-ID: Subject: Re: amd64: panic on -CURRENT @r330539 for certain UEFI hosts To: Konstantin Belousov Cc: Peter Lei , freebsd-current@freebsd.org, huanghwh@163.com, "Jonathan T. Looney" X-Mailman-Approved-At: Sat, 24 Mar 2018 00:35:57 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 23:06:25 -0000 On Fri, Mar 16, 2018 at 2:56 AM, Konstantin Belousov wrote: > On Thu, Mar 15, 2018 at 09:38:56PM -0500, Peter Lei wrote: > > Some recent UEFI implementations have begun to leave the CPU with page > > write protection enabled in CR0. > > > > With r330539 which enables kernel page protections, interesting things > > happen during boot (aka panic) when protection is already enabled, > > including a write protection fault from an explicit .text fixup write > > from xsave->xsaveopt by fpuinit(). > > > > I see this so far booting -CURRENT under virtual environments: > > > > - QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI > > enabling paging and page protections. > > > > - VMWare Fusion 10.1.x on Mac: no specific insight on what's going > > inside the implementation, but CR0_WP is definitely left enabled before > > the kernel is booted. > > > > I have patched my kernel build to explicitly clear CR0_WP (e.g. in > > initializecpu) prior to creating the page tables to get around this, but > > someone might have a cleaner/better solution... > > Try this. > > diff --git a/sys/amd64/amd64/db_interface.c b/sys/amd64/amd64/db_ > interface.c > index 9dfd44cf82c..1ecec02835c 100644 > --- a/sys/amd64/amd64/db_interface.c > +++ b/sys/amd64/amd64/db_interface.c > I ran into the original issue with r330539 on a Fusion VM. Trying this patch causes a different panic: https://people.freebsd.org/~mp/r330539-patched.png Thoughts? Mark