From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Matt Fleming <matt@console-pimps.org>
Cc: Matt Fleming <matt.fleming@intel.com>,
Ben Hutchings <ben@decadent.org.uk>,
Josh Boyer <jwboyer@redhat.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Seth Forshee <seth.forshee@canonical.com>
Subject: Re: efi: be more paranoid about available space when creating variables
Date: Tue, 26 Mar 2013 15:43:59 +0000 [thread overview]
Message-ID: <20130326154359.GA20530@srcf.ucam.org> (raw)
In-Reply-To: <51517A59.30002@console-pimps.org>
On Tue, Mar 26, 2013 at 10:37:13AM +0000, Matt Fleming wrote:
> Hmm... I'm not convinced this will provide a long-term solution. Is there
> anything that mandates that the size of all variables has to correlate
> sensibly
> with the results from QueryVariableInfo()? Even if there is in theory, I
> doubt
> it'll be true everywhere in practice, and trying to workaround
> implementation
> bugs in our workarounds for other bugs is the path to madness.
I'm not quite clear what you mean. We have a fairly solid idea as to
what the underlying problem here is, and I don't think this makes any
more assumptions than the existing code does.
> We can't continue this approach where we attempt to guess how the firmware
> implements variable storage, because as we've seen, there are various
> schemes
> out there. We're taking one step forward and two steps backwards at the
> moment
> with these kinds of patches. As you've seen, it's like playing
> whac-a-mole :-(
That's always been the way we end up dealing with firmware interactions.
Read the git log for the ACPI video driver for an example...
> I think, rather unfortunately, it comes down to solving these problems on a
> case-by-case basis. We've tried broad, all-encompassing solutions, but
> they're
> just not working. Lets contain the damage with a blacklist, because even
> if the
> list is really vague, i.e. "Apply size checks for all Samsung and Lenovo
> machines with Phoenix BIOS", it's still more relaxed than what we have
> now, and
> there's more chance of finding a single way to reliably workaround the
> bug if
> we restrict it to one IBV and a couple of OEMs.
I'm kind of reluctant, because the cost of getting this wrong is
hardware damage. Right now we believe that we're resistant to hardware
damage but have introduced another problem in the process. If we can
find a way to satisfy both constraints then I think that that's
worthwhile.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2013-03-26 15:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1364004995.3728.76.camel@deadeye.wl.decadent.org.uk>
[not found] ` <1364010441.3728.82.camel@deadeye.wl.decadent.org.uk>
[not found] ` <1364010441.3728.82.camel-nDn/Rdv9kqW9Jme8/bJn5UCKIB8iOfG2tUK59QYPAWc@public.gmane.org>
2013-03-23 20:24 ` efi: be more paranoid about available space when creating variables Fleming, Matt
2013-03-23 20:32 ` Matthew Garrett
[not found] ` <1364070731.2553.47.camel-tCUS0Eywp2Pehftex57rkxo58HMYffqeLoYNBG0abjxeoWH0uzbU5w@public.gmane.org>
2013-03-23 22:50 ` Matt Fleming
[not found] ` <514E31B0.4030305-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-03-26 3:56 ` Matthew Garrett
2013-03-26 4:31 ` Lingzhu Xiang
[not found] ` <5151248F.2010303-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-26 4:34 ` Ben Hutchings
2013-03-26 4:35 ` Matthew Garrett
[not found] ` <20130326035600.GA6209-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-03-26 7:40 ` Lingzhu Xiang
2013-04-01 15:13 ` [PATCH 1/2] efi: Determine how much space is used by boot services-only variables Matthew Garrett
[not found] ` <1364829240-26475-1-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-01 15:14 ` [PATCH 2/2] efi: Distinguish between "remaining space" and actually used space Matthew Garrett
[not found] ` <1364829240-26475-2-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-01 15:50 ` Ben Hutchings
2013-04-03 13:11 ` Matt Fleming
[not found] ` <515C2A86.6070606-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-04-03 13:48 ` Matthew Garrett
2013-04-03 17:12 ` Matt Fleming
[not found] ` <515C62E6.1070004-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-04-03 17:20 ` Matthew Garrett
2013-04-01 15:42 ` [PATCH 1/2] efi: Determine how much space is used by boot services-only variables Ben Hutchings
2013-04-03 13:09 ` Matt Fleming
[not found] ` <515C29EE.8050008-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-04-03 13:42 ` Matthew Garrett
2013-03-26 10:37 ` efi: be more paranoid about available space when creating variables Matt Fleming
2013-03-26 15:43 ` Matthew Garrett [this message]
[not found] ` <20130326154359.GA20530-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-03-27 9:09 ` Matt Fleming
[not found] ` <5152B75B.5080305-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-04-01 6:31 ` Ben Hutchings
2013-03-26 23:33 ` Seiji Aguchi
[not found] ` <A5ED84D3BB3A384992CBB9C77DEDA4D41AF79528-ohthHghroY0jroPwUH3sq+6wyyQG6/Uh@public.gmane.org>
2013-03-27 9:10 ` Matt Fleming
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=20130326154359.GA20530@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=ben@decadent.org.uk \
--cc=jwboyer@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=matt@console-pimps.org \
--cc=seth.forshee@canonical.com \
--cc=stable@vger.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).