From: Matt Fleming <matt@console-pimps.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
Matt Fleming <matt.fleming@intel.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
"Glenn P. Williamson" <glenn.p.williamson@intel.com>
Subject: Re: [PATCH 6/6] x86/efi: introduce EFI_BOOT_SERVICES_WARN
Date: Sun, 14 Sep 2014 16:18:47 +0100 [thread overview]
Message-ID: <20140914151847.GK18582@console-pimps.org> (raw)
In-Reply-To: <20140914000130.GC18296@nazgul.tnic>
On Sun, 14 Sep, at 02:01:30AM, Borislav Petkov wrote:
> On Sat, Sep 13, 2014 at 11:36:16AM -0700, Ricardo Neri wrote:
> > Being more verbose about this kind of illegal access from the firmware
> > increases the likelihood of this kind firmware bugs to be fixed.
>
> I sincerely hope you're right and, more importantly, how do we make sure
> those warnings get seen in time for a fix to even be possible..?
Some firmware teams do run Linux as part of their validation process,
and have been known to pay attention to the kernel boot messages. So
there's definitely hope there.
But we are also taking a more active approach with the Linux UEFI
Validation project [1], where we consume these kinds of error messages
and turn them into explicit test passes/failures.
We've been attending the UEFI plugfests and trying to work directly with
firmware engineers to bridge that communication gap between firmware and
OS, so that we can fix these kinds of bugs before they appear in the
wild.
[1] - https://01.org/linux-uefi-validation
--
Matt Fleming, Intel Open Source Technology Center
prev parent reply other threads:[~2014-09-14 15:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-13 18:36 [PATCH 0/6] Warn about illegal accesses to EFI_BOOT_SERVICES_* memory Ricardo Neri
2014-09-13 18:36 ` [PATCH 1/6] x86/efi: find mem descriptor from phys address Ricardo Neri
2014-09-13 18:36 ` [PATCH 2/6] x86/efi: use efi_memory_descriptor in convenience functions Ricardo Neri
2014-09-19 11:04 ` Matt Fleming
2014-09-13 18:36 ` [PATCH 3/6] x86/efi: add code to fixup page faults in BOOT_SERVICES_* regions Ricardo Neri
2014-09-13 18:36 ` [PATCH 4/6] x86/efi: remove __init attribute from memory mapping functions Ricardo Neri
2014-09-13 18:36 ` [PATCH 5/6] yx86/efi: fixup faults from UEFI firmware Ricardo Neri
2014-09-13 18:36 ` [PATCH 6/6] x86/efi: introduce EFI_BOOT_SERVICES_WARN Ricardo Neri
2014-09-14 0:01 ` Borislav Petkov
2014-09-14 15:18 ` Matt Fleming [this message]
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=20140914151847.GK18582@console-pimps.org \
--to=matt@console-pimps.org \
--cc=bp@alien8.de \
--cc=glenn.p.williamson@intel.com \
--cc=hpa@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=ricardo.neri-calderon@linux.intel.com \
/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