On 03/04/13 14:48, Matthew Garrett wrote: > On Wed, 2013-04-03 at 14:11 +0100, Matt Fleming wrote: > >> This looks like something that will differ between implementations, and the >> fact that it's appearing in our code is a sure sign that this isn't the way to >> go. > > Our choices right now are: > > 1) Break machines that don't garbage collect on every reboot > 2) Leave Samsungs (and some Lenovos?) vulnerable to bricking > 3) Maintain a whitelist or blacklist that will inevitably be inadequate, > either breaking otherwise working machines or risking bricking of broken > ones > 4) Attempt to implement something that'll work in all cases The solution you're proposing has the same downsides as 3) - we risk having to tweak things either way. The difference is that in the case of 3) the tweaking is adding entries to the whitelist, whereas tweaking your solution has more chance of introducing further unwanted regressions because you'd be tweaking an algorithm, an algorithm that relies on the internal implementation of the variable storage code. > Dealing with firmware is hard. This fixes (1) without leaving us with > (2), which seems like a net win. I'm not convinced that implementing 3) would inevitably lead to 2), provided that we apply a bit of common sense when adding entries. I'm not advocating some kind of flag day where we add umpteen machines to the whitelist. For reference, I just pushed two patches to the 'whitelist' branch at, git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git which should hopefully illustrate the kind of thing that I'm talking about. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
