On 26/03/13 03:56, Matthew Garrett wrote: > Ok, so having thought some more about the actual problem (ie, Samsungs > go wrong if there's too much used space marked as being active, not > merely too much used space) I think we really want to be looking for the > amount of active space rather than the remaining space value that > QueryVariableInfo() gives us. Something like this (absolutely untested, > provided here for comment) patch? I'll try rigging something up under > OVMF to test it. This version certainly seems a little over-naive, since > it won't handle the case of a variable that's being overwritten with > something of a different size. 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. 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 :-( 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. -- 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
