Re: amd64: panic on -CURRENT _at_r330539 for certain UEFI hosts

On Fri, Mar 16, 2018 at 2:56 AM, Konstantin Belousov <kostikbel_at_gmail.com>
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
>  <snip>


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