factory_shim: Enhance debugging ability. |
||||
Issue descriptionDue to security and privacy concern, we can't enable complete shell on factory (install/reset) shim unless we can confirm the user data on device has been really destroyed (or if the user has total control of it). Currently the factory_install.sh checks for firmware type = developer, which is enabled by ctrl-u boot, which mean user has either (1) finished ctrl-d, boot into OS for developer mode transition, wiped stateful, and rebooted, or (2) reflashed firmware with GBB flags set to enable dev boot. However, it is very inconvenient for factory or developers to debug in this case, especially if the internal storage device node (say /dev/nvme0n1) is missing. For some devices (which Gwendal has tried before), this was solved this by whitelisting serial numbers, but that may be not good enough. Usually people are simply looking for logs. So maybe we can enhance the (D)ebug log item into a debug console, that (according to b/69556815) provides all current items in debug menu, add: - dmesg - lspci -t - lspci -vvs 2:0.0 - smartctl -x [storage_device] - cgpt show [storage_device] - content of /usr/sbin/write_gpt.sh (on the factory shim) - dd if=/dev/[storage_device]p2 bs=512 count=1 status=none | od -xc -Ax - dd if=/dev/[storage_device]p4 bs=512 count=1 status=none | od -xc -Ax - full log from /sys/firmware/log And we found that current design (display via pager to scroll) is hard for remote debugging, so the debug console should: 1. Allow executing only particular command 2. Allow saving the contents to external storage (say USB stick, if the kernel can find it)
,
Nov 21 2017
Meanwhile, particular for "storage device missing", I wonder if we can add a check "if WP is disabled and no fixed drives in /sys/block, then we can open the shell" since there should be no data available to steal from?
,
Dec 19 2017
Also, we should add some hint when user tries to enter (S) Shell and failed due to system not allowing shell (not developer firmware). We should hint "if you need to debug try (D) for debugging" etc.
,
Dec 19 2017
#2. That's a security risk with storage devices connected via SATA cable or M.2 connector: I would open the case, remove them, boot without them and connect them once I am logged in the shell.
,
Dec 19 2017
#0. Newer factory images have 'd' option that prints most of what you described [see crbug/469163]
,
Feb 6 2018
Do I understand correctly that the concern here is for the debug shim to provide unfettered access to the encrypted stateful partition? In that case I'm not sure it's fair game to expose log data. (A user might have guest mode disabled and in that case access to log data would not be possible otherwise.) Maybe we need to add a debug flag to device settings which explicitly permits debug shim access?
,
Feb 6 2018
> Maybe we need to add a debug flag to device settings which explicitly permits debug shim access? If cros_debug is defined in kernel command line, then the factory shim will allow opening a shell. The problem is that Gwendal needs to debug on many shipped device that fail to complete developer mode transition (for example due to MMC error), so he can't boot devices with Ctrl-U (which is required for a self-signed debugging shim).
,
Feb 6 2018
Would it be possible to add a toggle to chrome://settings to allow disk inspection in normal mode?
,
Feb 6 2018
The device can't boot with eMMC, so only recovery mode is available. And we don't have browser in recovery mode.
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
,
Aug 15
Reassign to noogler as practice. |
||||
►
Sign in to add a comment |
||||
Comment 1 by hungte@chromium.org
, Nov 21 2017