Re: [PATCH v2 0/4] Add support for Chromium OS and Google WiFi

2021-01-17 Thread Paul Spooren
On Sat Jan 16, 2021 at 5:07 PM HST, Brian Norris wrote:
> Hi,
>
> This series adds support for both Chromium OS (or particularly, its
> kernel-payload signing and disk layout) and for a device using it (the
> first generation Google WiFi).
>
> Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
> decently supported by the existing ipq40xx target -- see patch 4 for
> more notes. Notably missing: reboot does not work properly -- I have
> some separate TrustZone/SCM-related patches I'd like to clean up to
> enable this later.
>
> I sent v1 as an "RFC" here:
> http://patchwork.ozlabs.org/project/openwrt/patch/20200718205148.1743807-6-computersforpe...@gmail.com/
> and since I got only mechanical feedback for the last patch, I'm now
> sending a non-RFC. I leave some notes about my implementation choices
> below, for reference.
>
> Changes since v1:
> * 1 patch was already merged
> * patch 4 is rebased, improved (see patch 4 for notes)
>
> Chromium OS (the open-source OS on which Google builds its Chrome OS) --
> "CrOS" for short -- typically boots via Coreboot, plus Depthcharge as a
> second stage. Such bootloaders utilize a verified boot toolkit [1] to
> verify each subsequent stage. Of note:
>
> 1. The kernel should be placed in a GPT partition with a custom "Chrome
> OS kernel" GUID type and a few custom flags (to manage the A/B
> OS updates employed by Chromium OS). CrOS vboot provides the `cgpt`
> utility for creating and managing such partitions.
> 2. That partition should hold a vboot payload, signed and packaged per
> the format documented and implemented at [1]. Using the vboot
> utilities, this involves the `vbutil_kernel --pack ...` command.
>
> I chose:
>
> (a) To extend OpenWRT's ptgen to help customize partition types,
> instead of packaging vboot's `cgpt`.
> (b) To adapt and reimplement the `vbutil_kernel` command as a custom
> `cros-vbutil` utility, rather than packaging Google's utility.
> (c) To add kernel and rootfs partition-size parameters (for customizing
> my GPT), but it's not clear to me if this fits well into the
> existing ipq40xx target, or if it should be done differently.
>
> For some alternatives (especially on (b)), I did package
> futility/vbutil_kernel here:
> https://github.com/openwrt/packages/pull/12829
> I could adapt this into tools/ instead, so OpenWRT doesn't have to carry
> my re-implementation. This would carry some extra build complexity,
> as the vboot tools are >10,000 lines of code, compared to my
> reimplementation of a few hundred lines. The library dependencies are
> similar (mostly just crypto/ssl, and potentially libuuid (for GPT)), as
> the vboot project tries to keep the code semi-portable / reusable.
>
> Packaging the vboot utilities might give us some future flexibility, if
> the formats grow and change for future systems. So far, I think the
> format has been pretty stable. Also, there are potentially some quirks I
> missed in my port related the ${ARCH} -- I ported the ARM support, but
> there may be some small tweaks I missed that are applicable only to x86
> systems.
>
> For (c): adding this to the common ipq40xx target means that there will
> be a new CONFIG_TARGET_KERNEL_PARTSIZE and
> CONFIG_TARGET_ROOTFS_PARTSIZE, which are only applicable to a single
> device but are present for all:
> FEATURES:=boot-part rootfs-part
>
> Regards,
> Brian
>
> [1]
> https://chromium.googlesource.com/chromiumos/platform/vboot_reference
>
> Brian Norris (4):
> firmware-utils/ptgen: add Chromium OS kernel partition support
> firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
> image-commands: support Chromium OS image-type creation
> ipq40xx: add target for Google WiFi (Gale)

I rebased the last patch onto 378c7ff282101b204d2a29fa080ed66f2a14940d
and fixed a typo which would break the vboot script. Changed are pushed
to my staging tree[2], let's see if my "staging" buildbots[3] like the
patch.

Thanks for your work!

[2]: https://git.openwrt.org/?p=openwrt/staging/aparcar.git;a=summary
[3]: https://buildmaster.aparcar.org/master/phase1/#/builders/56

>
> include/image-commands.mk | 18 +
> .../base-files/files/lib/upgrade/common.sh | 4 +-
> scripts/gen_image_vboot.sh | 36 ++
> target/linux/ipq40xx/Makefile | 2 +-
> .../ipq40xx/base-files/etc/board.d/02_network | 1 +
> .../base-files/lib/upgrade/platform.sh | 16 +
> .../arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 402 
> target/linux/ipq40xx/image/Makefile | 13 +
> .../901-arm-boot-add-dts-files.patch | 3 +-
> tools/firmware-utils/Makefile | 1 +
> tools/firmware-utils/src/cros-vbutil.c | 609 ++
> tools/firmware-utils/src/ptgen.c | 39 +-
> 12 files changed, 1138 insertions(+), 6 deletions(-)
> create mode 100755 scripts/gen_image_vboot.sh
> create mode 100644
> target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
> create mode 100644 tools/firmware-utils/src/cros-vbutil.c
>
> --
> 2.29.2
>
>
> ___
> o

[PATCH v2 0/4] Add support for Chromium OS and Google WiFi

2021-01-16 Thread Brian Norris
Hi,

This series adds support for both Chromium OS (or particularly, its
kernel-payload signing and disk layout) and for a device using it (the
first generation Google WiFi).

Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
decently supported by the existing ipq40xx target -- see patch 4 for
more notes. Notably missing: reboot does not work properly -- I have
some separate TrustZone/SCM-related patches I'd like to clean up to
enable this later.

I sent v1 as an "RFC" here:
http://patchwork.ozlabs.org/project/openwrt/patch/20200718205148.1743807-6-computersforpe...@gmail.com/
and since I got only mechanical feedback for the last patch, I'm now
sending a non-RFC. I leave some notes about my implementation choices
below, for reference.

Changes since v1:
 * 1 patch was already merged
 * patch 4 is rebased, improved (see patch 4 for notes)

Chromium OS (the open-source OS on which Google builds its Chrome OS) --
"CrOS" for short -- typically boots via Coreboot, plus Depthcharge as a
second stage. Such bootloaders utilize a verified boot toolkit [1] to
verify each subsequent stage. Of note:

 1. The kernel should be placed in a GPT partition with a custom "Chrome
OS kernel" GUID type and a few custom flags (to manage the A/B
OS updates employed by Chromium OS). CrOS vboot provides the `cgpt`
utility for creating and managing such partitions.
 2. That partition should hold a vboot payload, signed and packaged per
the format documented and implemented at [1]. Using the vboot
utilities, this involves the `vbutil_kernel --pack ...` command.

I chose:

 (a) To extend OpenWRT's ptgen to help customize partition types,
 instead of packaging vboot's `cgpt`.
 (b) To adapt and reimplement the `vbutil_kernel` command as a custom
 `cros-vbutil` utility, rather than packaging Google's utility.
 (c) To add kernel and rootfs partition-size parameters (for customizing
 my GPT), but it's not clear to me if this fits well into the
 existing ipq40xx target, or if it should be done differently.

For some alternatives (especially on (b)), I did package
futility/vbutil_kernel here:
https://github.com/openwrt/packages/pull/12829
I could adapt this into tools/ instead, so OpenWRT doesn't have to carry
my re-implementation. This would carry some extra build complexity,
as the vboot tools are >10,000 lines of code, compared to my
reimplementation of a few hundred lines. The library dependencies are
similar (mostly just crypto/ssl, and potentially libuuid (for GPT)), as
the vboot project tries to keep the code semi-portable / reusable.

Packaging the vboot utilities might give us some future flexibility, if
the formats grow and change for future systems. So far, I think the
format has been pretty stable. Also, there are potentially some quirks I
missed in my port related the ${ARCH} -- I ported the ARM support, but
there may be some small tweaks I missed that are applicable only to x86
systems.

For (c): adding this to the common ipq40xx target means that there will
be a new CONFIG_TARGET_KERNEL_PARTSIZE and
CONFIG_TARGET_ROOTFS_PARTSIZE, which are only applicable to a single
device but are present for all:
  FEATURES:=boot-part rootfs-part

Regards,
Brian

[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Brian Norris (4):
  firmware-utils/ptgen: add Chromium OS kernel partition support
  firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
  image-commands: support Chromium OS image-type creation
  ipq40xx: add target for Google WiFi (Gale)

 include/image-commands.mk |  18 +
 .../base-files/files/lib/upgrade/common.sh|   4 +-
 scripts/gen_image_vboot.sh|  36 ++
 target/linux/ipq40xx/Makefile |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/lib/upgrade/platform.sh|  16 +
 .../arch/arm/boot/dts/qcom-ipq4019-wifi.dts   | 402 
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 tools/firmware-utils/Makefile |   1 +
 tools/firmware-utils/src/cros-vbutil.c| 609 ++
 tools/firmware-utils/src/ptgen.c  |  39 +-
 12 files changed, 1138 insertions(+), 6 deletions(-)
 create mode 100755 scripts/gen_image_vboot.sh
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
 create mode 100644 tools/firmware-utils/src/cros-vbutil.c

-- 
2.29.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel