So the issue is that switching in and out of dev mode isn't clearing the TPM anymore. Is this an intended change?

Andrei, do you mind taking a look? 

Am I right that in both cases the the sequence was as follows?
1) Esc-Reload-Power to get to recover screen.
2) On recovery screen: "Ctrl-D", then "Enter" to turn OS verification OFF - leads to reboot.
3) On OS verification is OFF screen: "Space", then "Enter" to turn OS verification ON - leads to reboot.
4) Upon reboot, check if the old data was preserved.
Note that at no point in both videos there was a white powerwash progress screen. 

Afaiu, we never boot the OS until step 4, and reboot from depthcharge. All depthcharge does at those steps is setting various flags in nvram/tpm nvram. Powerwashing and clearing the tpm during mode transitions is done only when we actually start booting the OS - from chromeos_startup script. So, in both cases powerwash was not even attempted at least until step 4. 

I actually don't know what the right behavior should be in this case, when a switch to dev was requested, but then immediately 'canceled' and the device went back to normal mode before the transition to dev was performed. Is there any document that details that?

E.g. this help article https://support.google.com/chrome/a/answer/1360642 requests that at step 3 the user presses Ctrl-D to actually boot the OS in dev mode and perform powerwash, and only after reboot switch back to normal mode. So, the new behavior may be WAI.

I see the CL series starting with https://chromium-review.googlesource.com/c/493186 landed in 9593.0.0 (M61), and it could have affected the logic. Other differences between the boards (like a blocked dev mode) could also affected the outcome.

Hung-Te, could you please take a look if those CLs can be the reason for the differences in behavior? And what is the right behavior?

Also, note that the M61 board is gnawty, while M60 reference video is for snow, and the difference may be in firmware. The dev<->norm logic in both f/w branches seems to be similar, but the difference may be in some other parts of the f/w code: e.g. it clears the tpm upon reboot in one case, but doesn't do it in the other.

Was it attempted to boot an M60 image on gnawty and check how it behaves in this scenario?

 Issue 701292  may be related: both deal with when powerwash & clearing the tpm is actually performed.

First, what described in the issue is not "power wash", which has a special meaning.
The video is simply trying to enter and leave developer mode, and expecting to clear TPM as a side effect.

My change in CL:493186 is in userland (kernel) and TPM clear should be done by firmware, so I see nowhere my change to be suspicious, unless you you find that reverting that patch would solve this issue.

Re #11: Right, that's not powerwash. That's triggering wiping the stateful and clearing the tpm owner by going to dev mode and back (which is roughly equivalent to powerwash and is triggered through the same clobber-state/chromeos_startup mechanism, thus called 'powerwash' in an oversimplified manner in this bug).

The additional catch (see c#7) is that the transition to dev is not completed in the sequence of steps from the video: 'powerwash', or clearing the stateful + the tpm, is not started by the time the user requests the switch back to verified mode. And, as I said above, I don't even know what is the expected behavior in the case when transition to dev was canceled before it actually happened, should that 'powerwash' happen or not?

In any case: Clearing the tpm is done by the f/w. But it is requested by clobber-state script, which wipes the stateful data and signals to the f/w (crossystem clear_tpm_owner_request=1) that it should clear the tpm on the next boot: https://chromium.googlesource.com/chromiumos/platform2/+/master/init/clobber-state#433.
clobber-state in turn is called from chromeos_startup when the OS boots: https://chromium.googlesource.com/chromiumos/platform2/+/master/init/chromeos_startup#246.

The CLs I mention in c#8 change the chromeos_startup logic that decides when to call clobber-state and what parameters to pass to it, that's why it could have affected what happens in the case when the transition to dev mode is canceled before completing.

> wiping the stateful
Stateful won't be wiped if you never boot into the todev wiping screen (which has a progress bar).
i.e., in the step above, it simply reverts to normal mode, so no stateful wipe will be occured.

And the reason I think calling it powerwash would lead to misunderstanding is exactly what you mentioned in #12 - "powerwash" implies clearing stateful, while entering and leaving dev mode without entering "todev" wiping stage won't trigger that.

BTW, "clearing stateful", which is the one we've done in the CL, takes ~5mins is not seen in both videos. Which mean in either case, clobber-state was not executed. So, the reason you saw OOBE (no user list) is not related to powerwash or wiping of stateful partition.

Note that we only do the long thorough wipe or delay for 5 minutes if the mode is not "fast". I suspect we don't have the "powerwash progress" screen for "fast" wipes at all.

And "fast" is what happens on the transition from dev to prod. So, not seeing that wiping screen doesn't mean wipe_block_dev_fast() was not called.
It's still possible we used to do a powerwash in case of incomplete transition to dev, but don't do it anymore, e.g. after that CL from comment#8.

Still, the method of initiating powerwash by starting the switch to dev and then immediately switching back to prod before transition to dev even started doesn't seem to be a supported one. So, shall we close it as WonfFix/undefined behavior unless procedure from https://support.google.com/chrome/a/answer/1360642 also fails to work?

> I suspect we don't have the "powerwash progress" screen for "fast" wipes at all.
 The code from chromeos_startup and clobber-state tells:
 The transition from dev to prod still calls chromeos-boot-alert leave_dev, which shows a wiping script, except that it does not have the progress bar.
 And in clobber-state, no matter if 'fast' is enabled or not (except factory), clobbering will end with reboot.
 So not seeing wiping screen (and no reboot) clearly indicates wipe_block_dev_fast was not called.

Re #15: Oh, right. I played with 'fast' updates today - they do show the update screen, though briefly. And good point about the reboot - if there was a powerwash it should have ended with reboot.
So, actually, not clear why OOBE on older versions. W/o powerwashes with the newer version, it led to the predictable result.

Maybe "OOBE on old version" is related to the encrypted ext4 change.

apronin@ can you please share what next steps are here?

Marking as WontFix(WAI). Will create a separate lower-prio bug to check why this sequence led to OOBE on old builds.

Created issue 761078