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

Issue 874739 link

Starred by 1 user
Status: Assigned
Owner:
█ kirtika@chromium.org
Last visit > 30 days ago
Cc:
gwendal@chromium.org
vapier@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Disabling rootfs verification corrupts stateful

Project Member Reported by kirtika@chromium.org, Aug 16 
OS: 10973.0.0

What steps will reproduce the problem?
Tried on eve with nvme, <redacted device with nvme> and coral with emmc. 
(1) /usr/share/vboot/bin/make_dev_ssd --remove_rootfs_verification
--partitions <2 or 4> 
(2) reboot
(3) try to ssh in and touch /foo

What is the expected result?
- either ssh fails (stateful is corrupted, device can be pinged
but cannot ssh in, python is gone, and so is /usr/local/bin). 
OR
- rootfs verification disabling was partial. Can
do "touch /var/lib/foo" but not "touch /foo" even after
a "mount -o remount,rw /" 



Please use labels and text to provide additional information.

If this is a regression (i.e., worked before), please consider using the
bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help
us identify the root cause and more rapidly triage the issue.

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

Comment 1 by vapier@google.com, Aug 16 

/var is always writable, so that doesn't say anything about the rootfs

does the boot say anything about recovering stateful?

what does the usr/share/vboot/bin/make_dev_ssd output show exactly?

Comment 2 by kirtika@chromium.org, Aug 16 

Sorry, I meant "/lib/firmware/foo" not "/var/lib/foo". 

For a machine where roots verification removal was done previously, here's 
some output: 

ssh root@kbench-eve
Password: 
localhost ~ # ls
bytes-rootfs-prod
localhost ~ # touch /foo
touch: cannot touch '/foo': Permission denied
localhost ~ # mount -o remount,rw / 
localhost ~ # touch /bar
touch: cannot touch '/bar': Permission denied
localhost ~ # touch /lib/firmware/foo

"touch /foo" should work after rootfs verification is disabled.

Comment 3 by vapier@chromium.org, Aug 16

Summary: Disabling rootfs verification corrupts stateful (was: Disabling rootfs verification either doesn't work fully or corrupts stateful)
failure to create files in / has nothing to do with rootfs verification.  that is an selinux denial you can see in `dmesg`.  whether that's intentional is up for debate.  you can file a new bug about that, but otherwise should have nothing to do with stateful corruption.  lets focus on that part.

how often do you see stateful reset after disabling rootfs verification ?

Comment 4 by vapier@chromium.org, Aug 16 

i've filed  issue 874980  for the selinux changes if you want to track that

Comment 5 by kirtika@chromium.org, Aug 17 

@vapier: I've lost repro of the stateful corruption. I had it 2/2 on my A50 and A70 i7+nvme units on 10971.0.0/10973.0.0. I'll update the bug when I have a repro again.

Comment 6 by kirtika@chromium.org, Aug 17

Owner: kirtika@chromium.org
Status: Assigned (was: Untriaged)
►

Sign in to add a comment