mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bhupesh Sharma <bhsharma@redhat.com>
To: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Neri, Ricardo" <ricardo.neri@intel.com>,
	"matt@codeblueprint.co.uk" <matt@codeblueprint.co.uk>,
	Al Stone <astone@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER
Date: Sat, 8 Sep 2018 00:19:34 +0530	[thread overview]
Message-ID: <e10acaa8-f5d8-85f3-219c-86fafd793a87@redhat.com> (raw)
In-Reply-To: <FFF73D592F13FD46B8700F0A279B802F485BA5C1@ORSMSX114.amr.corp.intel.com>

On 09/07/2018 11:53 PM, Prakhya, Sai Praneeth wrote:
> >> There may exist some buggy UEFI firmware implementations that might
> >> access efi regions other than EFI_RUNTIME_SERVICES_<CODE/DATA> even
> >> after the kernel has assumed control of the platform. This violates
> >> UEFI specification.
> >>
> >> If selected, this debug option will print a warning message if the
> >> UEFI firmware tries to access any memory region which it shouldn't.
> >> Along with the warning, the efi page fault handler will also try to
> >> recover from the page fault triggered by the firmware so that the
> >> machine doesn't hang.
> >
> > Why make this optional?
>
> I made it as a config option in RFC because the page fault handler was
> complicated and touching many parts (it had lots of code change and I didn't want
> to break any existing functionality). Now that it's simple, I don't think we need
> the config option.
>
> Without efi page fault handler, any page fault caused by firmware should panic
> kernel but with this patch I think we are just improving existing condition (ideally).
>
> So, if Thomas, Ingo, Andy, Ard and Boris are ok.. I will make it as default (i.e. without
> config).
>
> Regards,
> Sai
>
Also, some distributions already have specific ways to handle buggy firmwares which can be at times dependent on the underlying hardware and the firmware versions.

I would suggest that we enable this under a CONFIG for the first round and once it is tested with wider variety of x86 machines which have buggy or orphaned firmware and linux (and reboot) works fine with them, we can drop the CONFIG option in future and enable this by default.

Regards,
Bhupesh

  reply	other threads:[~2018-09-07 18:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 23:27 [PATCH V4 0/3] Add efi page fault handler to recover from page Sai Praneeth Prakhya
2018-09-06 23:27 ` [PATCH V4 1/3] efi: Make efi_rts_work accessible to efi page fault handler Sai Praneeth Prakhya
2018-09-06 23:27 ` [PATCH V4 2/3] x86/efi: Add efi page fault handler to recover from page faults caused by the firmware Sai Praneeth Prakhya
2018-09-07 11:21   ` Peter Zijlstra
2018-09-07 18:29     ` Prakhya, Sai Praneeth
2018-09-06 23:27 ` [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER Sai Praneeth Prakhya
2018-09-07 11:22   ` Peter Zijlstra
2018-09-07 18:23     ` Prakhya, Sai Praneeth
2018-09-07 18:49       ` Bhupesh Sharma [this message]
2018-09-07 19:08         ` Prakhya, Sai Praneeth
2018-09-07 19:22           ` Thomas Gleixner
2018-09-07 19:55             ` Bhupesh Sharma
2018-09-07 20:13               ` Thomas Gleixner
2018-09-07 10:42 ` [PATCH V4 0/3] Add efi page fault handler to recover from page Ard Biesheuvel
2018-09-07 18:32   ` Prakhya, Sai Praneeth
2018-09-07 19:03 ` Bhupesh Sharma
2018-09-07 19:13   ` Prakhya, Sai Praneeth

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=e10acaa8-f5d8-85f3-219c-86fafd793a87@redhat.com \
    --to=bhsharma@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=astone@redhat.com \
    --cc=bp@alien8.de \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ricardo.neri@intel.com \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=tglx@linutronix.de \
    --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

all inboxes | Powered by JetHome®