Is there any way to patch a standard Chrome OS image?

[Marcos Scriven]

I'm trying to tweak a standard Chrome OS image to use on a Chromebook in dev mode, but short of directly manipulating bits, I'm just trying to mount partitions in the image as read/write.

This works:

mount -o ro,loop,offset=983564288 chromeos.bin /mnt/chromeroot

But the moment I try to mount as rw I see:

mount: wrong fs type, bad option, bad superblock on /dev/loop0,

       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try

       dmesg | tail or so.

And in dmesg:

[ 5088.841508] EXT4-fs (loop0): couldn't mount RDWR because of unsupported optional features (ff000000)

Looking at http://www.chromium.org/chromium-os/developer-guide I think this may be due to rootfs verification? 

Is there any way to do this with standard unix tools? I'd rather not have to build a whole image just for minor changes.

[Marcos Scriven]

Just to follow up, I ran tune2fs -l on the mounted (ro) partition:

sudo tune2fs -l /dev/loop0

tune2fs 1.42.12 (29-Aug-2014)

Filesystem volume name:   ROOT-A

Last mounted on:          /tmp/tmp.2U8OkKKnnH

Filesystem UUID:          <none>

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file FEATURE_R24 FEATURE_R25 FEATURE_R26 FEATURE_R27 FEATURE_R28 FEATURE_R29 FEATURE_R30 FEATURE_R31

Filesystem flags:         signed_directory_hash

Default mount options:    user_xattr acl

Filesystem state:         clean

Errors behavior:          Remount read-only

Filesystem OS type:       Linux

Inode count:              48000

Block count:              192000

Reserved block count:     0

Free blocks:              155960

Free inodes:              44073

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      46

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         8000

Inode blocks per group:   500

Filesystem created:       Fri Apr 28 04:41:37 2017

Last mount time:          Fri Apr 28 04:59:39 2017

Last write time:          Fri Apr 28 04:59:39 2017

Mount count:              12

Maximum mount count:      -1

Last checked:             Thu Nov 19 19:00:00 2009

Check interval:           0 (<none>)

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:          256

Required extra isize:     32

Desired extra isize:      32

Default directory hash:   half_md4

Directory Hash Seed:      0a6b0ba8-b210-432d-9808-0c4e5d24b508

 I'm assuming the "FEATURE_Rn" features are proprietary Chrome OS verification features. I guess I'll have to manually create a new image, and manually copy over from a ro mounted partition.

[Marcos Scriven]

I think I've found my answer here https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/firmware-leon-4389.61.B/scripts/image_signing/make_dev_ssd.sh#257

# disable the RO ext2 hack

debug_msg "Disabling rootfs ext2 RO bit hack"

enable_rw_mount "$ssd_device" "$root_offset_bytes" >"$EXEC_LOG" 2>&1 ||

  err_die "Failed turning off rootfs RO bit. OS may be corrupted. " \

          "Message: $(cat "$EXEC_LOG")"

That function is here https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/aaae959412acc95ba2f4a0b5af44d67186c7a3d2/scripts/image_signing/common.sh#168

# For details, see crosutils.git/common.sh

enable_rw_mount() {

  local rootfs="$1"

  local offset="${2-0}"

  # Make sure we're checking an ext2 image

  if ! is_ext2 "$rootfs" $offset; then

    echo "enable_rw_mount called on non-ext2 filesystem: $rootfs $offset" 1>&2

    return 1

  fi

  local ro_compat_offset=$((0x464 + 3))  # Set 'highest' byte

  # Dash can't do echo -ne, but it can do printf "\NNN"

  # We could use /dev/zero here, but this matches what would be

  # needed for disable_rw_mount (printf '\377').

  printf '\000' |

    sudo dd of="$rootfs" seek=$((offset + ro_compat_offset)) \

            conv=notrunc count=1 bs=1

}

[Mike Frysinger]

correct

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Marcos Scriven]

So I was able to edit the recovery image - but it fails, and in  the logs I see:

ChromeosChrootPostinst(9334.41.3)

Set boot target to /dev/mmcblk0p3: Partition 3, Slot A

SetImage

KERNEL_CONFIG: console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 1536000 verity payload=PARTUUID=%U/PARTNROFF=1 hashtree=PARTUUID=%U/PARTNROFF=1 hashstart=1536000 alg=sha1 root_hexdigest=25009619ed1c7b8e4eae62d0d4cc7f794507d4d6 salt=8da0ac678592acf6395953f6dca6310b5682844dc5ae70c2e96c88474c273afa" noinitrd vt.global_cursor_default=0 kern_guid=%U coherent_pool=2M  

Setting up verity.

Filesystem hash verification failed

Expected 25009619ed1c7b8e4eae62d0d4cc7f794507d4d6 != actual 9ef77d0723f743c8cd5daadc83865d795eabb729

Finished after 36 seconds.

SetImage failed.

PostInstall Failed

But:

dev_boot_signed_only   = 0  

Why is the filesystem hash still being verified?

[Bill Richardson]

make_dev_ssd.sh changes the kernel cmdline args, but you still have to reboot in order for it to take effect. You also have to provide the --remove_rootfs_verification arg. Try make_dev_ssh.sh --help first.

--

Art for Art's Sake

Engineering for Money

[Marcos Scriven]

Hmm - to answer my own question again - I think I misunderstood 'dev_boot_signed_only'. That's just for booting from USB, not SSD

I think therefore as part of the modification I'll have to use make_dev_firmware.sh to resign the image prior to postinst.

[Marcos Scriven]

Ah - crossed posts Bill

So I *don't* have to write dev keys to the firmware?

[Bill Richardson]

No. There's a make_dev_firmware.sh for that. 

[Marcos Scriven]

Yes - that's what I mentioned in previous post:

"I think therefore as part of the modification I'll have to use make_dev_firmware.sh to resign the image prior to postinst."

Will look into that.

[Mike Frysinger]

you shouldn't need to mess with dev keys if your goal is to just test boot some images

-mike

[Julius Werner]

On Wed, Jul 12, 2017 at 8:11 AM, Marcos Scriven <mar...@scriven.org> wrote:

Hmm - to answer my own question again - I think I misunderstood 'dev_boot_signed_only'. That's just for booting from USB, not SSD

dev_boot_signed_only does affect SSD boots, but it doesn't do what you think. It makes the firmware verify the kernel partition with official keys, which you don't want. Just leave it off.

make_dev_firmware.sh replaces the keys in your firmware with dev keys. You don't need to do this. You would need to remove your firmware write protection for that, but as long as you are in dev mode your firmware will already not care about the official keys, so don't bother with this.

However, even in dev mode the firmware still checks the hash of the kernel partition stored at the start of that partition (just not whether this hash is signed correctly), and the kernel still checks the filesystem hashes through verity. You have to change your kernel command line to disable verity, and then resign the kernel (with developer keys) to make the kernel partition hash right again. The code for both of those things should be somewhere in make_dev_ssd.sh (the kernel resigning should be a call to vbutil_kernel). If you do that, the recovery installer should notice that you have disabled verity in the command line and no longer give you that postinstall error.