New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 860835 link

Starred by 7 users

Issue metadata

Status: Verified
Owner:
Closed: Jan 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Devices, deprovisioned from FRE OU still forbid Developer Mode

Project Member Reported by vkhabarov@chromium.org, Jul 6

Issue description

ChromeOS version: v62-67.0.3396.87
ChromeOS device model: Enguarde, Reks and Lulu 
Case#: 16175687

Description:
Deprovisioning some devices, belonging to FRE OUs, would clear force-enrollment requirement, but still would forbid entering Developer Mode. Wipe doesn't help. But logging in with any account (enrollment or just logging in) would allow to enter Developer Mode later. Not all devices repro this issue, so far reported on Lenovo N21/N22 and Dell 13 (lulu). Chell, for example, WAI. Customer has this issue with v62 devices, but v67 still has the issue too.


Steps to reproduce: 
1. Enroll device
2. Move device to FRE OU
3. Deprovision device
4. Wipe device
5. Try to move to Developer Mode

Current Behavior / Reproduction:
Device would show message that Developer Mode is forbidden and switches back to regular

Expected Behavior: 
Device would allow to switch to Developer Mode

Drive link to logs: 
Log after wipe, unsuccessful  attempt to enter DevMode and logging in with Gsuite account - 
https://drive.google.com/open?id=1LvcfO6eaXwikdMteSJsjUBzgSLd-OPrh

Log after previous steps and actually entering DevMode -
https://drive.google.com/open?id=17LiVEXe-m5tUCmO5kzdCQKBd2SJ5MCaN
 
Cc: atwilson@chromium.org
this seems like expected behavior if the device has not yet synced and seen the 	
DeviceBlockDevmode policy no longer set. Can you clarify how much time is occurring between step 3 and 4?

+ atwilson my understanding is that DeviceBlockDevmode=true policy will set block_devmode=1 in VPD (which survives wipe/powerwash). Is there any chance for us to clear block_devmode=1 during OOBE or do we have to wait for re-enrollment attempt then?
re #c1
I've checked again, yes, if you add refresh policy step, DevMode would become available. 
Status: WontFix (was: Untriaged)
Marking this as WAI since we can't really do anything with this (without network connection and policy fetch it's not possible for the device to know it has been deprovisioned). Please reopen if you disagree.
Status: Available (was: WontFix)
Well, yes, I disagree - device receives information that it's no longer force-enrolled and deprovisioned after it starts and configures.
Agreed that it feels like we can do better here though this may be an FR rather than a bug.

When device reaches OOB and has network connectivity can't we check and possibly clear block_devmode in VPD at that time?
Labels: -Type-Bug Type-Feature
Owner: maxkirsch@chromium.org
Assigning FR to Max to prioritize.
Cc: pmarko@chromium.org
Hello team,

Do we have an update on this issue? vkhabarov@chromium.org
Cc: maxkirsch@chromium.org
Owner: igorcov@chromium.org
Status: Assigned (was: Available)
OK, repro steps aren't clear. In step 5, are you setting up a network and then doing an FRE check, and *then* you're still stuck with blocked dev mode?

Also, I don't even understand comment #2 - what does "add a refresh policy step" mean - you aren't enrolled, so how can you refresh policy?

Anyhow, assigning to Igor to follow up. At what point do we clear the block_devmode flag after FRE check returns "no FRE"?
christianelias: re comment #8, we're considering this as WAI, it's expected right now that device must sync with server to get the message that it's been deprovisioned and remove force re-enroll / dev mode disable settings. If you own a case about this please point customer at this FR, explain this is a current product limitation and let's close out.

The FR here is to also clear devmode block if the device has been deprovisoned server-side but wiped locally.

@atwilson: Think we'd need to check in with server-side team to see if this is even possible?
"sync with server" - just doing an FRE check should be sufficient, shouldn't have to re-enroll and grab policy. So it should "just work" as long as they aren't trying to put the device in dev mode before connecting it to the network.
Btw I tested this again and the FRE check IS sufficient. You do not need to re-enroll.

I'm unclear what the bug / FR is here exactly.
Owner: aoldemeier@chromium.org
Status: Started (was: Assigned)
We currently only clear the firmware management parameters once we get the response at OOBE that FRE is not required.

For  https://crbug.com/876328  we implement an additional DBus call to be called here that sets check_enrollment=0 in RW_VPD.


I will extend this DBus call to also set block_devmode=0 in RW_VPD.
Project Member

Comment 14 by bugdroid1@chromium.org, Dec 6

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

commit d32fe3658d6ba4e32fb621213b317ea9ecbdcc0c
Author: Alex Oldemeier <aoldemeier@chromium.org>
Date: Thu Dec 06 13:54:39 2018

login: Extend ClearCheckEnrollmentVpd DBus call to also set block_devmode=0.

ClearCheckEnrollmentVpd was meant to be called from Chrome once OOBE retrieves
the information that FRE is not required. However, according to another bug
we also need to set block_devmode=0 here. Since the call is not yet made from
Chrome it makes sense to simply extend and rename ClearCheckEnrollmentVpd.

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

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

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

Project Member

Comment 15 by bugdroid1@chromium.org, Dec 18

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

Project Member

Comment 16 by bugdroid1@chromium.org, Jan 11

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

commit 3f691c1fbfd52cc9a9deefe21ec04f851b7f1ba0
Author: Alex Oldemeier <aoldemeier@chromium.org>
Date: Fri Jan 11 17:48:01 2019

login: Also set block_devmode=0 in system properties when clearing FRE VPD.

This fixes a bug with the clearing of FRE flags at OOBE for de-provisioned
devices. For devices with FRE and blocked dev mode, block_devmode will also
have been set to 1 in system properties, which prevents going back to
dev mode. This additional action should be removed again once the system
property check for dev mode blocking is removed.

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

Change-Id: I202b6085a70a5e0664096c98bf7f2b56e5afad67
Reviewed-on: https://chromium-review.googlesource.com/1403121
Commit-Ready: Alex Oldemeier <aoldemeier@chromium.org>
Tested-by: Alex Oldemeier <aoldemeier@chromium.org>
Reviewed-by: Yusuke Sato <yusukes@chromium.org>

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

Status: Fixed (was: Started)
Tested with an eve and signed recovery dev image 11580.0.0 from GoldenEye as follows:

- In verified mode: recovered with mentioned image.
- Enrolled device into my testorg (testorg-aoldemeier) with FRE and block devmode on.
- Checked that I cannot switch to dev mode.
- Deprovisioned device and forced stateful clear by bouncing through the dev mode dialogue (which showed "dev mode is blocked" and "Go back to verified mode with a clear".
- Went through the FRE check at OOBE ("Determining device configuration").
- Rebooted with ESC+F2, pressed CRTL-D and was able to activate dev mode.
Status: Verified (was: Fixed)
as per #17

Sign in to add a comment