| 26 Nov 2024 |
 @jack:unredacted.org | * Yeah, not even AOSP's extract_kernel.py can make some sense out of pvmfw.img.unpacked/kernel.
| 21:06:41 |
| @jack:unredacted.org | * Maybe I should try checking if platform/build/+/master/tools/extract_kernel.py can make some sense out of it.
| 21:06:48 |
| @jack:unredacted.org | Aside from this, I've also used unpack_bootimg.pyto unpack the boot.img. That one has a perfectly normal ARM64 kernel image, but diffoscope still shows a large diff when comparing two builds of the same boot.img.unpacked/kernel. Do I need to preprocess this kernel image somehow before comparing? Not sure if I need to strip signatures from the image or how to do this, by the way.
| 21:14:19 |
| @jack:unredacted.org | * Aside from this, I've also used unpack_bootimg.py to unpack the boot.img. That one has a perfectly normal ARM64 kernel image, but diffoscope still shows a large diff when comparing two builds of the same boot.img.unpacked/kernel. Do I need to preprocess this kernel image somehow before comparing? Not sure if I need to strip signatures from the image or how to do this, by the way.
| 21:14:29 |
 samueldr | jack: when I hit a weird filetype, especially when it's likely others have it it, searching its filename in github code search helps... when you know how to use it, which is non-obvious: use a regex to search
| 21:14:54 |
| @jack:unredacted.org | In reply to @samueldr:matrix.org
jack: when I hit a weird filetype, especially when it's likely others have it it, searching its filename in github code search helps... when you know how to use it, which is non-obvious: use a regex to search
That's a good idea. Thanks. | 21:15:32 |
| samueldr | given I see Protected VM firmware image along it, maybe that's not "just" a linux kernel | 21:16:05 |
| samueldr | even though it's packaged within the "container" of an android boot image | 21:16:24 |
| @jack:unredacted.org | In reply to @jack:unredacted.org
Aside from this, I've also used unpack_bootimg.py to unpack the boot.img. That one has a perfectly normal ARM64 kernel image, but diffoscope still shows a large diff when comparing two builds of the same boot.img.unpacked/kernel. Do I need to preprocess this kernel image somehow before comparing? Not sure if I need to strip signatures from the image or how to do this, by the way.
Any idea on this one? | 21:16:48 |
| samueldr | https://github.com/GrapheneOS/platform_packages_modules_Virtualization/tree/9ec1c44084125875aa9619635e4e6fdf3172b57c/pvmfw#integration | 21:17:07 |
| samueldr | In reply to @jack:unredacted.org
Any idea on this one? nope | 21:17:27 |
| @jack:unredacted.org | In reply to @jack:unredacted.org
Aside from this, I've also used unpack_bootimg.py to unpack the boot.img. That one has a perfectly normal ARM64 kernel image, but diffoscope still shows a large diff when comparing two builds of the same boot.img.unpacked/kernel. Do I need to preprocess this kernel image somehow before comparing? Not sure if I need to strip signatures from the image or how to do this, by the way.
boot.img unpacked perfectly and has a perfect ARM64 kernel image, but I personally don't know how to compare different kernel images, maybe I have to strip signatures like I successfully did with the kernel modules before. | 21:18:06 |
| @jack:unredacted.org | In reply to @jack:unredacted.org
Aside from this, I've also used unpack_bootimg.pyto unpack the boot.img. That one has a perfectly normal ARM64 kernel image, but diffoscope still shows a large diff when comparing two builds of the same boot.img.unpacked/kernel. Do I need to preprocess this kernel image somehow before comparing? Not sure if I need to strip signatures from the image or how to do this, by the way.
* | 21:18:20 |
| samueldr | | 21:18:41 |
| samueldr |
The pVM firmware (pvmfw) is the first code executed by a pVM, similar to the boot ROM of a physical device.
| 21:18:52 |
| samueldr | so it's definitely not a linux kernel | 21:19:09 |
| @jack:unredacted.org | Yes, maybe unpack_bootimg.py isn't prepared to handle it, so it just considers whatever is in the supposed kernel position on the file.
| 21:20:19 |
| 27 Nov 2024 |
 oak 🏳️🌈♥️ | I got a little forward by creating the FHS env, but I still can't completely run the mk-vendor-file.py for new Chromium version, now I get same errors I think it tries to pull some Google internal stuff they use for building ChromeOS and Chrome | 20:40:12 |
| 26 Nov 2024 |
| @jack:unredacted.org | Apparently there is some tools I can build to handle pvmfw stuff: m pvmfw-tool pvmfw_bin
| 21:23:26 |
| 27 Nov 2024 |
| oak 🏳️🌈♥️ | * I got a little forward by creating the FHS env, but I still can't completely run the mk-vendor-file.py for new Chromium version, now I get some errors I think it tries to pull some Google internal stuff they use for building ChromeOS and Chrome | 20:40:18 |
| 26 Nov 2024 |
| @jack:unredacted.org | * Apparently there are some tools I can build to handle pvmfw stuff: m pvmfw-tool pvmfw_bin
| 21:23:37 |
| 28 Nov 2024 |
| oak 🏳️🌈♥️ | Actually it looks like there could be some useful stuff in how nixpkgs packages chromium | 03:04:42 |
| 27 Nov 2024 |
| @jack:unredacted.org removed their profile picture. | 16:57:53 |
| @jack:unredacted.org removed their display name jack. | 16:57:54 |
| @jack:unredacted.org left the room. | 16:57:55 |
| 28 Nov 2024 |
 atemu12 | Ideally we'd have a little pkgs.chromium.override { withAndroid = true; withWebview = true; } and it'd spit out an APK | 11:23:36 |
| atemu12 | You could ask the upstream maintainers whether they'd accept you building in support for that | 11:24:05 |
| atemu12 | (Upstream as in Nixpkgs upstream.) | 11:24:16 |
| 1 Dec 2024 |
|  mighty-heron joined the room. | 12:38:10 |
|  @statecode47:unredacted.org joined the room. | 18:13:56 |
