Add Hungte note from cl/689962 review:
No. Factory shim only boots if ctrl-d (devsw_cur) has been enabled. "maintw_type?developer" is the one that checks if the device has finished wipe transition and enabled developer mode (i.e., ctrl-u).
In other words, If you check only Ctrl-D, people can boot and get a shell in 5 seconds without wiping stateful partition
If you check mainfw_type?developer, people will need 5 minute transition, enter root and enable, and have all user data wiped.

My answer:
But data can not be wiped if you can boot from the device, so we will never reach mainfw_type == developer.

If check_enrollment was not set, on a machine with dev mode enabled, I could modify a recovery image to go to a shell and see encrypted user data anyway.

the system being overly bricked such that you can't wipe things isn't an excuse to bypass the timing restrictions for all devices.

wrt check_enrollment, your proposal is for bypassing both scenarios, not just the one.  so even if we added it behind a check_enrollment check, it wouldn't help you in your current situation.

there are two pieces of state we care about here ... the tpm and the stateful disk data.  can we find a way to allow the dev shell when the disk is hosed (like no /dev/ nodes), and keep the tpm state sufficiently inaccessible from dumping ?

Why don't you just go through recovery with an official recovery image? Or are you saying the root device is physically broken? If so, why do you care about the machine at all? ;-)

> My answer: But data can not be wiped if you can boot from the device, so we will never reach mainfw_type == developer.

Maybe there's some misunderstanding, but people do get mainfw_type=developer if they have fully control of the device, and not trying to access the stateful partition without getting things wiped. This can be done by
  - First install a recovery image (and get stateful wiped), run enable_usb_boot, then Ctrl-U to boot factory shim.
  - Or, use the (I)nstall option from a factory shim, which will re-initiate and wipe stateful.

In short, we do need to make sure people can't access to data created in normal mode.

> If check_enrollment was not set, on a machine with dev mode enabled, I could modify a recovery image to go to a shell and see encrypted user data anyway.

You need to first define what is the "dev mode" here. If you mean "boot in recovery mode with virtual dev switch turned on", I think that will only boot a signed (unchanged) recovery image, so you can't get a shell.
If you mean "boot in developer mode firmware (mainrw_type?developer)", i.e., boot with Ctrl-U, then yes you can boot a modified recovery image, but then you can also use factory shim to get (S) - that's exactly what we're checking here.

> Why don't you just go through recovery with an official recovery image? Or are you saying the root device is physically broken? If so, why do you care about the machine at all? ;-)

yes, the root device is malfunctioning.  Gwendal needs to debug it to figure out what's gone wrong (possibly at the firmware level).

we're trying to see if there's a more general solution here than Gwendal having to (temporarily) hardcode specific serial #'s in the signed image.

I think we may open the shell if we can't find any non-removable storage. Will that help in this case? Or it can be found and simply fail to boot?

> and no servo connector

I thought it's simply no servo header soldered and if you can find a HW or EE engineer to help, it is still possible to enable server by soldering a new header?

in talking to Gwendal, i think the failure mode might not be that clear :(.  it might be that the device enumerates (so /dev/mmcblk0 shows up), but the data under it (e.g. the GPT) cannot be read.  but we can't really differentiate between "the GPT has been corrupted, but stateful data is still in there somewhere" and "the disk is hosed".

Can gwendal provide what he wants to do in the shell?

Another solution is to provide a "diagnosis tool" instead of complete shell. For example, ToT factory shim provides a "Debug information" command that will collect the output from a bunch of commands like dmesg, messages, ... etc.

You'd have to check with the enterprise folks, but maybe allowing a shell when wpsw_boot=0 would be OK?

#3, #7: as #9 indicated, /dev/mmcblk0 is present, but not readable.

#8 is possible. It is not just the servo header though, usually, the associated discretes are removed too.

#10: My intent was to enable boot from USB or remove the entreprise enrollement from the RW VPD and launch a shell to retrieve some mmc information:
- mmc extcsd read ... (running get_storage_info)
- cat /sys/kernel/debug/mmc*/ios
I can add these to the D option of the factory image.

> allowing a shell when wpsw_boot=0 would be OK

i guess the assumption is that the attacker has enough time with the device to disassemble it and remove the wp screw and thus would have enough time to reprogram the flash iff they had the hardware (a bus programmer)

we've in the past said that long term local attackers aren't something we really protect against, so it wouldn't be going against that ...

is there a way we could lock the tpm and put it into a state where it wouldn't give up key material until next reboot ?  guessing not ...

> we've in the past said that long term local attackers aren't something we really protect against,

That's probably no longer true since we put a lot of effort to disable smart students and enterprise enrolled units to be reflashed and then entering developer mode.

Re#12

Feel free to add those commands. We can merge this to ToT for all devices as well, since that's pretty safe in comparison to giving complete shell.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/factory_installer/+/1b562e77bbf6d78cf012be30019a05f110034ba9

commit 1b562e77bbf6d78cf012be30019a05f110034ba9
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Nov 30 09:13:05 2017

factory_install: use storage_info

Use storage_info script to gater storage information.
It collects information on all fixed devices (SATA, eMMC, NVMe).

BUG=chromium:770235
CQ-DEPEND=CL:567300
TEST=On cyan, check we are seeing mmc ext_csd information.
Previously we were just looking at /dev/sda, the USB stick most of the time.

Change-Id: Ic6a1adc39dab7f2d7f9feabf5f2425b1b0a96401
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/701400
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>

[modify] https://crrev.com/1b562e77bbf6d78cf012be30019a05f110034ba9/factory_install.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/factory_installer/+/feea9f2a1eb90c6d60a48c0fa2cd322dd34eb095

commit feea9f2a1eb90c6d60a48c0fa2cd322dd34eb095
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Thu Nov 30 20:19:33 2017

factory_install: use storage_info

Use storage_info script to gater storage information.
It collects information on all fixed devices (SATA, eMMC, NVMe).

BUG=chromium:770235
CQ-DEPEND=CL:567300
TEST=On cyan, check we are seeing mmc ext_csd information.
Previously we were just looking at /dev/sda, the USB stick most of the time.

Change-Id: Ic6a1adc39dab7f2d7f9feabf5f2425b1b0a96401
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/701400
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 1b562e77bbf6d78cf012be30019a05f110034ba9)
Reviewed-on: https://chromium-review.googlesource.com/801776
Reviewed-by: Gwendal Grignou <gwendal@google.com>
Commit-Queue: Gwendal Grignou <gwendal@google.com>
Tested-by: Gwendal Grignou <gwendal@google.com>

[modify] https://crrev.com/feea9f2a1eb90c6d60a48c0fa2cd322dd34eb095/factory_install.sh

Hi Gwendal, do you think this issue can be closed, or do you expect more changes?