bnorris
January 11, 2025, 5:59pm
21
It was linked up thread.
This is needed in the main openwrt tree (it was merged recently, so you can just sync to the latest):
openwrt:main ← computersforpeace:vboot
opened 10:34PM - 26 Jul 24 UTC
This PR consists of a few patches to improve OpenWrt's interaction with Chromium… OS "vboot"-related tooling on OnHub and Google WiFi routers. ChromiumOS vboot (verified boot) tooling [1] helps interact with the Write Protection mechanisms on the boot SPI flash, and with understanding and modifying various bootloader flags, signing and verification properties, and kernel packaging.
I've had these patches around for a while, but they've proved useful to others recently [2], so I felt like it's time to publish them properly.
With luck, the mtd/spi-nor patch will be uncontroversial upstream. I had to tweak the flags structure a bit to backport to kernel 6.6, but it should be functionally identical.
[1] https://github.com/openwrt/packages/pull/12829
[2] https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899/701?u=bnorris
Then you need this for packages.git, because it still is pending:
openwrt:master ← computersforpeace:cros-vboot
opened 01:59AM - 16 Jul 20 UTC
This new package is useful for systems that have Chrome OS bootloaders,
which u… se Google's vboot_reference stack for signing and verifying
kernel payloads. Such bootloaders also tend to allow booting custom
(non-Google-signed) payloads when in Developer Mode, using published
developer keys or their own, or their own provided keys (if rebuilding
their own bootloader).
There are a variety of other scripts and binaries built within this
repository, but at the moment, we're installing:
* cgpt: ChromeOS GPT tool, for manipulating partitions, especially
Chrome OS kernel partitions and their associated partition attributes
* crossystem: CrOS System tool, for manipulating various system and
bootloader/NVRAM properties, like making default boot-disk selection,
retrieving the firmware revision, and querying special system pin
states. Some functionalities only work when helpers like "mosys"
(https://chromium.googlesource.com/chromiumos/platform/mosys) are
present (not packaged here), but there are still a few useful entries
in here.
* futility: a mutli-call binary providing several utility functions.
I'll quote part of its --help output:
The following commands are built-in:
create Create a keypair from an RSA .pem file
dump_fmap Display FMAP contents from a firmware image
dump_kernel_config Prints the kernel command line
gbb Manipulate the Google Binary Block (GBB)
gbb_utility Legacy name for `gbb` command
help Show a bit of help (you're looking at it)
load_fmap Replace the contents of specified FMAP areas
pcr Simulate a TPM PCR extension operation
show Display the content of various binary components
sign Sign / resign various binary components
update Update system firmware
validate_rec_mrc Validates content of Recovery MRC cache
vbutil_firmware Verified boot firmware utility
vbutil_kernel Creates, signs, and verifies the kernel partition
vbutil_key Wraps RSA keys with vboot headers
vbutil_keyblock Creates, signs, and verifies a keyblock
verify Verify the signatures of various binary components
version Show the futility source revision and build date
* tpmc: small TPM utility
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Maintainer: me
Compile tested: ARM/ipq4019, OpenWrt master
Run tested: ARM/ipq4019 (Google WiFi), OpenWrt master
NB: I am prepping OpenWRT support for a Chromium OS based AP, and it will need some of these utilities in the base tools. I have the necessary bits slimmed down and partially rewritten for inclusion there, but the full package is still useful for development and debugging on-device.
agarg
January 11, 2025, 6:03pm
22
Thanks, I am on the road but will try that in a week. Appreciate your help.
Udjin
January 17, 2025, 8:40am
23
I can confirm that was able to boot with USB flash inserted into HUB without issues, I have no USB dongles to test, but I think it will boot too.
agarg
January 17, 2025, 6:20pm
24
Sorry, I was travelling.
I just tested with 7 USB devices. The hub used is this one:
[226129.867375] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
[226129.944450] hub 4-1:1.0: USB hub found
[226129.945280] hub 4-1:1.0: 4 ports detected
[226130.057024] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[226130.279959] hub 3-1:1.0: USB hub found
[226130.280248] hub 3-1:1.0: 4 ports detected
[226456.033006] ath10k_pci 0000:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[226763.339319] ath10k_pci 0000:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
In all but one cases, including one with a wifi dongle, it survived a power cycle and rebooted fine. The one case where is failed when the USB drive was in the USB hub was with a 4GB older kingston 4GB USB drive with the first being a FAT16 partition. I also tested with an mSATA-USB (128gb) connected to the hub and to trouble there too at reboot.
I am not planning to use the USB port of the primary gateway, just as a precaution. In my case, I do have other devices, on this network, with unused USB ports.
I think, it OnHub is a remarkable device with beefy storage, RAM and CPU. To have a sophisticated firewall on it and save it from landfill is just a super service.