Re: efi: be more paranoid about available space when creating variables

[Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>]

On 26/03/13 15:43, Matthew Garrett wrote:
> 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.

Right, it doesn't make more assumptions, but the assumptions that the
existing code makes is causing problems, hence the need for your updated
patch. I'm fully expecting that the updated patch will also cause us
problems/require additional patches. I really don't want to keep
patching/tweaking this all the way to -rc6 and beyond.

Have you tested this patch against one of those machines that suffers
from the original bricking problem? Ben, does this patch fix your issue?
I dug my buggy-as-hell ASUS machine out from under my desk and it
suffers from the max_size == 0 problem which this patch doesn't fix, but
that's already been discussed.

> 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.

I'm concerned we're going to end up introducing more constraints because
some other class of platforms doesn't work with this patch. It expects
DataSize and storage_size to correlate meaningfully, and I'm not at all
convinced that will be true everywhere, even though it's not an
unreasonable expectation.

Maybe we should leave the existing checks in place and create a
whitelist for those machines that absolutely must be able to write to
the variable store, e.g. to initiate garbage collection, or where
QueryVariableInfo() is known to be inaccurate, or where we know we can
have the full use of pstore without bricking the machine. Yes, we'll
have to maintain the whitelist and we'll no doubt get bug reports for
machines that need to be added to the list, but at least no one is going
to brick their laptops, and the fix is simply adding an ID to the list,
not reimplementing our workarounds with the risk of breaking X number of
machines that were previously working just fine.

-- 
Matt Fleming, Intel Open Source Technology Center