[Galaxy Note GT-N7000 General] Entropy512:
No they couldn't be sued for fraud. As I stated - while we've seen a handful of people claim they experienced damage from stock recovery (nonsecure erase), in the second round of claims I approached those people to try and get their devices to Samsung for analysis. Two just sent their devices to the factory instead, one never answered me. Without a concrete example of eMMC damage caused by non-secure erase, there is nothing available to properly contradict their claim.

There is nothing wrong with their software in their opinion - see above, they are dead-on certain that non-secure erase as implemented by their stock recovery is safe. Unless someone who experiences damage in Samsung's stock recovery that didn't fakeflash CWM or try to flash it some other way can step up and provide an example AND provide it to Samsung for analysis, we don't have a leg to stand on here.

My contact asked why developers didn't look at the source code and see that secure erase was not used - I pointed out that source code for Samsung's own recovery is not available. Long after this fiasco started we were able to establish that it does nonsecure erase by instrumenting kernels - but it took a while to do this, and open source developers had already started removing all forms of erase from binaries at this point.

Their original opinion was that opensource developers should just remove secure erase from their recovery binaries. After I explained the situation of update-binaries in flashable zips, that's when they started to realize that kernel-level protection was actually necessary.

Put to rest? Maybe. If any more users experience damage, we'll be able to finally have evidence for Samsung that nonsecure erase has issues. I will always worry about those few rare reports from users claiming to suffer damage in stock recovery - Did they actually suffer damage in stock recovery, or were they doing something other than what they claimed to be doing? Even if not intentionally lying, some users are just plain stupid and might have done damage before or after their wipe in stock recovery. I can't be sure - the fact that in the latest round of claims of stock recovery damage, no user "stepped up" to provide their device to Samsung seems fishy. (As to the first round with XXLPY on N7000 - Unfortunately, that was before we had contacts at Samsung to try and send such devices to, and all of the units from that round are long since replaced...)

I made it clear that these future fix deployments by Samsung had to be, in some manner, verifiable in a running binary as to their presence. I have a post-meeting action to provide some examples of how this might be done. For example, the fix could be designed so that it is an option enabled in the kernel defconfig - combined with enabling IKCONFIG in the kernel, someone could check the configuration of the running binary. (Added benefit for opensource developers - we can see the exact config used for an official kernel instead of guessing based on the defconfigs in a source release, which don't always match the running kernel.)

An interesting thing that I learned as I tried to reproduce it on their sacrificial test devices - even secure erase may only have a 10-20% chance of causing damage. Also, if you survive the first erase your chances are much better at surviving the next. I can't go into details as to the exact conditions where the problem triggers, I will however say that the typical I/O patterns that occur on an Android device's /data partition are about the worst case situation (bad luck for Samsung there...). However, one would have to be using a device for a period of time to put the system in a state where wiping will do the damage. This is probably one of the reasons why there are always "spikes" of damage reports whenever Samsung deploys the trigger conditions for damage to a device that has never seen wipes before.

There are still some disconnects that need to be resolved... Someone thinks that all I9100 binary releases have MMC_CAP_ERASE - but we know that this isn't the case. The person that claimed that may have been looking at sdhci.c and not realizing it was mshci.c. Also another one of their engineers (who was not present at the meeting, but was supporting from elsewhere) was adamant that MMC_CAP_ERASE couldn't be completely removed because it was needed for performance reasons AND that they were using it for file discard/trim - and yes, while erasing MMC sectors in advance will improve write performance, and this performance can be maintained if the filesystem is mounted with the "discard" option - I have not seen a filesystem mounted with this option on ANY Samsung firmware release. I think we've seen evidence that there are some internal communications issues Samsung needs to work on even within the Mobile division. (Keep in mind that Mobile is a seperate business unit from Memory and they don't necessarily like each other...)