linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Joerg Roedel <jroedel@suse.de>
Cc: Guenter Roeck <linux@roeck-us.net>,
	linux-kernel@vger.kernel.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Michal Hocko <mhocko@suse.com>, Andi Kleen <ak@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Hansen <dave.hansen@intel.com>, Pavel Machek <pavel@ucw.cz>,
	linux-efi@vger.kernel.org, x86@kernel.org
Subject: Re: Random crashes with i386 and efi boots
Date: Tue, 11 Sep 2018 11:05:25 -0700	[thread overview]
Message-ID: <51FDF5AF-2FE8-4817-9A5C-8CE4A8BC23AB@amacapital.net> (raw)
In-Reply-To: <20180911174158.7qu6f4vfnfzqqrcf@suse.de>



> On Sep 11, 2018, at 10:41 AM, Joerg Roedel <jroedel@suse.de> wrote:
> 
> On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote:
>>>   save_pgd = efi_call_phys_prolog();
>>>   local_irq_save(flags);
>>>   status = efi_call_phys(...);
>>>       local_irq_restore(flags);
>>> 
>>>       efi_call_phys_epilog(save_pgd);
>>> 
>>> So, yes, interrupts are very much enabled.
>> 
>> Does fixing that solve the problem?  It seems more robust.
> 
> 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?
> 
> So I am in favor of changing the order in efi_call_phys_epilog() too.
> 

I’m rather confused here.  We’re loading CR3 with page tables that don’t have the fixmap mapped?  With interrupts on?  And we expect 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 GDT reload entirely.

2. Do this whole virtual map dance earlier so we don’t have IRQs and NMIs and such. Maybe while we’re still using the initial page table?

3. Just identity map all the EFI regions. Make EFI page tables that literally map them at their physical addresses *and* map the entire kernel, just like we do for normal user mms.

Sure, as a stopgap, turning off IRQs and applying Guenter’s patch seems okay, but this code is not okay.

  parent reply	other threads:[~2018-09-11 18:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 21:56 Random crashes with i386 and efi boots Guenter Roeck
2018-09-11 11:52 ` Andy Lutomirski
2018-09-11 13:30   ` Guenter Roeck
2018-09-11 16:36     ` Andy Lutomirski
2018-09-11 17:41       ` Joerg Roedel
2018-09-11 17:59         ` Linus Torvalds
2018-09-11 17:59         ` Guenter Roeck
2018-09-11 18:05         ` Andy Lutomirski [this message]
2018-09-11 18:22           ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51FDF5AF-2FE8-4817-9A5C-8CE4A8BC23AB@amacapital.net \
    --to=luto@amacapital.net \
    --cc=ak@linux.intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dave.hansen@intel.com \
    --cc=jroedel@suse.de \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mhocko@suse.com \
    --cc=pavel@ucw.cz \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).