| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Linux 3.0.101 which is used in Replicant 6.0, the
kernel size increased a lot.
Because of that, in Replicant 11, the recovery initramfs is
compressed with xz to fit in the 8MiB RECOVERY partition of
the Galaxy SIII (GT-I9300) and Galaxy SIII 4G (GT-I9305).
Having the ability to add root to Replicant 11 recovery
images helps a lot with the development or configuration
of the recovery and install procedure as with this script
we can have a shell in the recovery (to look at partitions,
retrieve logs, etc) without needing to boot and setup
Replicant.
This script was also tested a Replicant 11 recovery on a
Galaxy SIII (GT-I9300), and once flashed the recovery boots
and we can get a shell with 'sudo adb shell'.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
| |
They are not used by the code handling pure zImage KERNEL
and RECOVERY images.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While abootimg git[1] has no new commits since 2021, FSO's
unbootimg is not maintained at all as work on the
Freesmartphone.org has stopped.
As abootimg is used by diffoscope and it is pakcaged by
Debian and Guix, so it's probably better to use to abootimg
since more people will more likely already have it in the
distribution they use and since it's a dependency of
diffoscope we are more likely tools with the same command
line interface in the future than the interface of FSO's
unbootimg.
I added a package for abootimg 6.0 in Parabola and Aur in
order to make it easier for Parabola users to transition
from fso-unbootimg to abootimg.
[1]https://github.com/ggrandou/abootimg
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without that fix, running 'make test-recovery-i9300' twice
produces two different images.
With diffoscope we can see that the only differences between
the two images are the gzip timestamps of the initramfs and
the bootimage ID:
--- tests/recovery-i9300-with-root.img.1
+++ tests/recovery-i9300-with-root.img
├── abootimg -i {}
│ @@ -13,9 +13,9 @@
│ * load addresses:
│ kernel: 0x40008000
│ ramdisk: 0x41000000
│ tags: 0x40000100
│
│ * cmdline = console=ttySAC2,115200
│
│ -* id = 0xbdaf2901 0x9c9b846c 0x229caf97 0x9a73b1e6 0x1403c772 0x00000000 0x00000000 0x00000000
│ +* id = 0x7551c944 0x85dcc898 0xbce08232 0x6de196b1 0x39ac56b5 0x00000000 0x00000000 0x00000000
├── initrd.img
│ ├── filetype from file(1)
│ │ @@ -1 +1 @@
│ │ -gzip compressed data, was "ramdisk.cpio", last modified: Thu Sep 30 18:02:46 2021, from Unix
│ │ +gzip compressed data, was "ramdisk.cpio", last modified: Thu Sep 30 18:02:53 2021, from Unix
As in the current mkbootimg python implementation, the ID is
generated from the checksum of various components of the
image, just fixing the gzip command fixes the tests.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works but it's currently too fragile:
- For the zImages, it relies on the compressed image being smaller,
if not we need to at least append the size of the compressed Image
to the zImage
- It doesn't autodetect much, for instance we need to autodetect the
compression type (xz, lzma, gzip, etc).
- The bootimages are not reproducibles (probably because a random ID
is added to the image). This prevents adding some easy testing where
we could automatically download some Replicant 6 images and add root
to them and compare the result with some checksums.
The source code also has additional TODOs inside it.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the key-migration.sh script only migrated the keys the
first time it ran. To do that, in that first run, it also creates the
/data/system/.key-migration-done file, and in subsequent runs it skips
the key migration if that file was present.
It probably did that to not redo the same operations again and again
either to limit the data loss risk by not doing any filesystem writes
and/or to speedup the boot process.
However if we have more than one maintainer or keyset changes over time,
users will need to run this script the first time, and at the second
change later on, the new script will not run. In addition users also need
to be able to create such script themselves and run them whenever they
need to in order to migrate to self builds, or downgrade.
Using a revision system to do that would be error prone as users and
developers would need to not forget to bump the revision to make the
script run. Using an automatic revision with the hash of the script
content also has issues as running the same script twice (for instance
by doing an upgrade, then a downgrade and then an upgrade) wouldn't
work.
Running the script each time ensure that all uses cases work, at the
cost of speed: in the recovery, with all Replicant 4.2 and 6.0 keys
up to Replicant 6.0 0004 RC2, running the script takes about 5s on
a Galaxy SIII (GT-I9300):
# time sh ./key-migration.sh
Key migration done
0m4.55s real 0m1.07s user 0m3.18s system
We also ensured that no writes were made to the packages.xml file
if nothing had to be changed. This increases the risk during the
key update as no backup of the packages.xml is done, however this
decreases the risk subsequently as no writes are made anymore.
Prints were also added to inform the user of if the script ran fine,
and if not why it didn't.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
The applications built from Replicant are signed with a key that is
generated during the build procedure The issue is that the data of an
application becomes inaccessible to it if the application signature change.
This affects all the applications built during and signed during the build
of Replicant images, which includes all system applications.
This is why, during the installation of a new Replicant version, the
otasigcheck.sh is run: it verifies if the application signatures expected
by the applications data match the signatures of the new applications
that are part of the new Replicant image being installed.
Without this check, users installing a new Replicant minor version (like
Replicant 6.0 0004) and keeping the data from the previous minor version
(like Replicant 6.0 0003) with a key that change will make at least some
system applications like the launcher crash as they will not be able to
access their data.
If the check detects an incompatibility, on a Galaxy SIII (GT-I9300), we
end up the installation aborting and the following message being displayed
on the screen:
detected filesystem ext4 for /dev/block/mmcblk0p12
Can't install this package on top of incompatible data. Ples
se try another package or run a factory test
E:Failed to install /sideload/package.zip
E:Please take note of all the above lines for reports.
This design has several issues:
- You cannot upgrade between Replicant minor versions if the keys signing
applications shipped in the new version changed. This is really
problematic as to upgrade, users need to delete all their application
data and restart creating them from scratch which is very time consuming.
With frequent updates that would becomes too much time consuming to do.
- It is also very fragile: if the data partition is encrypted,
otasigcheck.sh cannot do the check, and the check is skipped completely,
with the consequences explained before (the system applications end up
not being able to access their data).
To fix that:
- This patch adds a new python script for generating the key-migration.sh
script that will be added to the vendor_replicant repository.
Generating the key-migration.sh script with a python script enables users
and developers to generate a key-migration.sh script with the keys they
want. This should make downgrade easier as the key-migration.sh script
could also be run manually in the recovery and also make the migration to
self-built images much easier.
- The generated script (key-migration.sh) will be added to the
vendor_replicant repository. It will take care of migrating the
applications data to the new keys during the first boot (so after the
data partition will have been mounted).
- The call to otasigcheck.sh during the installation of new Replicant
versions will be removed in the build repository.
- otasigcheck.sh will be removed in the vendor_replicant repository.
Also, the otasigcheck.sh script has already been removed in LineageOS 17.1
by the following commit in vendor/lineage:
commit 95621f3c73b94a87ca4528748535bb114ae1613f
Author: Michael Bestas <mkbestas@lineageos.org>
Date: Sat Aug 4 17:46:35 2018 +0300
Revert "ota: Validate any installed data's signature against our own"
* otasigcheck doesn't work on encrypted devices and makes
the zip installation fail since oreo.
* The build part of this was never ported to oreo.
This reverts commit aff5e54c4ef5fec7e67e830f83ee64424005d07c.
Change-Id: I411f33c1db64844091c1692ef4706ae541925d4f
This key-migration.sh script has been generated by the following command in
the Replicant source code directory:
$ ./vendor/replicant-scripts/images/gen_key_migration_script/gen_key_migration_script.py \
gen-script \
vendor/replicant/prebuilt/common/bin/key-migration.sh \
vendor/replicant-data/distros/releases/certificates/ \
vendor/replicant-security/
This work is based on the following commit from the android_vendor_cm
repository[1]:
2f7c7decc Add startup script to update the package signatures
commit 2f7c7decc4cd5b42f044a7841a74468e4cacd694 (refs/changes/27/156327/3)
Author: Gabriele M <moto.falcon.git@gmail.com>
Date: Fri Jan 13 17:03:45 2017 +0100
Add startup script to update the package signatures
This allows to jump straight to LineageOS without wiping
userdata first.
Change-Id: I208bcada9380cbd69f3bec6c64e3c9e0eb1104c8
[1] https://github.com/LineageOS/android_vendor_cm.git
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
