So I'm still not clear - check_enrollment=1 should never be set for devices that have not been at least once enrolled to an enterprise domain. So what's the actual repro case here for these devices (starting from factory state)?

It sounds like we're saying:

1) Take a factory-fresh device.
2) Enroll to an enterprise domain with FRE enabled - this sets check_enrollment=1.
3) Trigger stateful clear through bouncing through dev mode.
4) Now, at OOBE, try to powerwash without signing in or otherwise completing OOBE
5) Shortcut doesn't work because check_enrollment=1

So, it seems like:

a) we should always be able to powerwash at OOBE, regardless of the state of check_enrollment. Disabling powerwash shortcuts is just a convenience feature we added for EDU customers to prevent students wiping devices, but if we're at OOBE already there's no need to do it.
b) if server says the device isn't in FRE, we should clear check_enrollment immediately. No need to wait.

I believe the device is being refurbished, so it was previous enrolled.

Assigning to Alex, to set the check_enrollment flag to zero when we get response from server that no FrE is required.

BTW I think I've seen similar things (chrome initiating setting a VPD flag)
implemented using a dbus call to debugd.

igorcov via monorail <monorail+v2.2972849587@chromium.org> schrieb am Mi.,
5. Sep. 2018, 11:09:

Yea, the plan is to initiate a dbus call that will end up running /usr/sbin/update_rw_vpd in a separate process.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/dfd468666bb1f8e362f75de79f10536b9a40c720

commit dfd468666bb1f8e362f75de79f10536b9a40c720
Author: Alex Oldemeier <aoldemeier@chromium.org>
Date: Thu Nov 29 20:11:11 2018

login: Add DBus call to SessionManager to clear check_enrollment flag.

It will be called from Chrome auto_enrollment when a re-enrollment
check returns that the device is deprovisioned. This ensures
that powerwash is not blocked at OOBE for deprovisioned and
refurbished devices.

BUG= chromium:876328 
TEST=Run login_manager tests
TEST=dbus-send --system --print-reply --type=method_call --dest=org.chromium.SessionManager /org/chromium/SessionManager org.chromium.SessionManagerInterface.ClearCheckEnrollmentVpd

Change-Id: If484b2a2deb4ba1061bb9891a4d345dce0b375f7
Reviewed-on: https://chromium-review.googlesource.com/1342637
Commit-Ready: Alex Oldemeier <aoldemeier@chromium.org>
Tested-by: Alex Oldemeier <aoldemeier@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/device_policy_service.cc
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/session_manager_impl_test.cc
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/mock_device_policy_service.h
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/device_policy_service_test.cc
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/SessionManager.conf
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/session_manager_impl.cc
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/dbus_bindings/org.chromium.SessionManagerInterface.xml
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/device_policy_service.h
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/system_api/dbus/login_manager/dbus-constants.h
[modify] https://crrev.com/dfd468666bb1f8e362f75de79f10536b9a40c720/login_manager/session_manager_impl.h

I have added a DBus call to SessionManager to set check_enrollment=0 (see above).

There is experimental code to make this call in Chrome once we get the response that FRE is not required. I have tested it and it works (see https://chromium-review.googlesource.com/c/chromium/src/+/1348029).

However:

The check for whether the powerwash screen is to be shown (see https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/core_oobe_handler.cc?g=0&l=433) uses StatisticsProvider, which iiuc loads all its data into memory when Chrome is started. This means that the update to RW_VPD is only available and effective after a reboot.

Now, we can of course (i) trigger a reboot after the DBus call was successful or (ii) also update the key-value pair in memory somehow. However, option (i) might be unintuitive for the user and (ii) is not provided with the current implementation of StatisticsProvider (the intention seems to be that it is read-only after it has been initialized). So adding an exception for check_enrollment seems at least a little bit hacky.

We could of course (iii) also do nothing in addition, which would mean that the user needs to reboot once. Maybe this is acceptable in the special case where someone wants to trigger powerwash at OOBE after a device has been deprovisioned.

I would like to ask for thoughts here, especially because the VPD clearing is to be extended to devmode (un)blocking. Once we have a solution to the check_enrollment case, such an extension will be easy, but I want to make sure we go for the proper solution first.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60

commit 6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60
Author: Alex Oldemeier <aoldemeier@chromium.org>
Date: Tue Dec 18 11:50:25 2018

Set FRE VPD flags to 0 at OOBE when device is not forced to re-enroll.

Make a DBus call to login_manager when the re-enrollment check
at OOBE returns that the device is not forced to re-enroll. This
call sets block_devmode and check_enrollment to 0 in RW_VPD,
ensuring that powerwash is not blocked at OOBE and entering
dev mode is permitted for deprovisioned and refurbished devices.

Bug:  860835 ,  876328 
Test: browser_tests --gtest_filter="WizardController*"
Change-Id: I2a70c4430082dba5c797866f86362dcf7b9edeee
Reviewed-on: https://chromium-review.googlesource.com/c/1348029
Reviewed-by: Denis Kuznetsov <antrim@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Reviewed-by: Igor <igorcov@chromium.org>
Commit-Queue: Alex Oldemeier <aoldemeier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617447}
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chrome/browser/chromeos/login/enrollment/auto_enrollment_controller.cc
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chrome/browser/chromeos/login/enrollment/auto_enrollment_controller.h
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chrome/browser/chromeos/login/wizard_controller_browsertest.cc
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/fake_cryptohome_client.cc
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/fake_cryptohome_client.h
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/fake_session_manager_client.cc
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/fake_session_manager_client.h
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/session_manager_client.cc
[modify] https://crrev.com/6e7c0e5f517740b1af69ba6cb33f0f5ae06a7c60/chromeos/dbus/session_manager_client.h

check_enrollment is now set to 0 when the device gets the response that the device is not forced to re-enroll.

As described above, with the current "fix" there is no more sign-in required, but it still requires a reboot after the first OOBE cycle, since the powerwash shortcut handler uses a cached value to determine whether the dialogue will be shown. After a reboot the cached value is updated and the shortcut works.

Please let me know whether this is acceptable. Otherwise, I can look into one of the options (i) or (ii) above.

Steps followed.
1) Take a factory-fresh device.
2) Enroll to an enterprise domain with FRE enabled - this sets check_enrollment=1.
3) Trigger stateful clear through bouncing through dev mode.
4) Now, at OOBE, try to powerwash without signing in or otherwise completing OOBE
5) Shortcut doesn't work because check_enrollment=1

Observation:
Alt+Ctrl+Shift+r shortcut does nothing.

Esc+Reload+Power takes to recovery mode.
Cannot switch to dev. mode as FRE is enabled and device boots to OOBE screen.
Able to enroll device to forced domain.

Checked on Google Chrome(73.0.3664.0,11540.0.0) coral babymega. Marking the issue as verified for now.

Igor and I have just discussed the history and user experience regarding power wash at OOBE and login, which resulted in the creation of a follow-up bug whose resolution would also cover part a) of Drew's comment #1 --- since the CL linked here only covers part b). The solution proposed there will also resolve the issue described in comment #10:

https://bugs.chromium.org/p/chromium/issues/detail?id=923296