Can downgrade with same patch level?

raccoondad

Watermelon does the recovery's OTA sideload feature accept older GrapheneOS builds with the same underlying security patch level?

No, they are signed with a timestamp, the timestamp of a new update must be => of the timestamp of the OS update on the device.

Watermelon

de0u This is relevant but doesn't answer the question. Specifically, it says: "This includes providing downgrade protection, which prevents attempting to downgrade the version. If recovery didn't enforce these things, they would still be enforced via verified boot including downgrade protection".

It says the recovery protects from downgrades, which is true but doesn't specify how.
It says it prevents downgrading the version but doesn't specify if it only prevents downgrades to versions with a lower security patch level or lower build number.
And it says that verified boot itself enforces the same things as the recovery enforces, but I know that verified boot enforces downgrade protection based on the security patch level and not the build number, which implies that it would accept any OTA package of GrapheneOS so long as it's properly signed and has at least an equal patch level as currently installed.

raccoondad No, they are signed with a timestamp, the timestamp of a new update must be => of the timestamp of the OS update on the device.

May I ask how you know?

raccoondad

Watermelon May I ask how you know?

Attempt to flash a lower build #

de0u

Watermelon I am 100% not an expert on this, so maybe an expert will chime in, but here's what I think I see.

In bootable/recovery/install/install.cpp, InstallResult() checks ViolatesSPLDowngrade() from install/spl_check.cpp, which appears to consult ro.build.version.security_patch, which in my build trees appears to be a security patch level of the sort that turns up in the GrapheneOS changelog (it is not the date that the build occurred).
But also in install/install.cpp CheckPackageMetadata() calls CheckAbSpecificMetadata(), which consults ro.build.date.utc, which I think is an actual build timestamp, though maybe it isn't for the emulator, and before I could figure out exactly how that property gets set I'm afraid I got lost in the build system.
Other things are checked too... ro.build.fingerprint of the current system is checked against the "package pre-build fingerprint" if there is one.

So I think a security patch level is checked and I think a build timestamp is checked. And other things may be checked depending on the package contents.

Watermelon

raccoondad Attempt to flash a lower build #

I don't want to sound obnoxious but sometimes it's necessary to ask simple questions like "have you tried turning it off and on again". So may I ask which build you had installed and which you were trying to sideload, if you remember?

de0u Thank you for the info

Watermelon

de0u I checked the file you mentioned. I found a spelling mistake in the source code:
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L73
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L163
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L223

I found this comment in the same file:
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L147-L149
From what I could understand (I'm likely wrong somehow) from skimming over this file, there's four things:

Security patch level: never allowed to be downgraded — enforced by the recovery sideloading and by verified boot.
Build ID: never allowed to be downgraded — enforced by the recovery sideloading.
"Incremental" version: allowed by the recovery sideloading to be downgraded only if the OTA update package is explicitly marked as a "downgrade" package.
Build date/timestamp: allowed by the recovery sideloading to be downgraded only if the OTA update package is explicitly marked as a "downgrade" package.

It seems that the security patch level is the most coarse-grained version, the build ID is more fine-grained, and the "incremental" version number is the most fine-grained version number. It seems that the GrapheneOS team puts their build numbers as both the build ID and the "incremental" version number, identically.

de0u

Watermelon So may I ask which build you had installed and which you were trying to sideload, if you remember?

Have you been able to downgrade via sideloading an old build? If so, which build were you running and which were you able to sideload?

Watermelon

de0u Have you been able to downgrade via sideloading an old build? If so, which build were you running and which were you able to sideload?

I haven't tested it, and I don't have a second device to test it on, sadly.

de0u

Watermelon I haven't tested it, and I don't have a second device to test it on, sadly.

That's understandable.

At this point I believe we have some reason to believe that the code in Recovery checks both a build timestamp and a security patch level, and we have a report (admittedly not super-detailed) that a user got an error about a build timestamp.

From the code, I expect the error would be "Update package is older than the current build, expected a build newer than timestamp NNNNN but package has timestamp MMMMM and downgrade not allowed", which would be straightforward to interpret. The error message for a security patch level discrepancy is quite different.

Watermelon

de0u expected a build newer than timestamp NNNNN

Should be said, I've seen the GrapheneOS project recommending users with boot failures to try to sideload the current OS version in the recovery in order to reinstall the OS, so it seems like it accepts at least the current build rather than only newer builds.

de0u

Watermelon I've seen the GrapheneOS project recommending users with boot failures to try to sideload the current OS version in the recovery in order to reinstall the OS, so it seems like it accepts at least the current build rather than only newer builds.

I quoted the message from the code, not the code itself. The message might be off-by-one in the way you suggest. I'm not going to have time for at least a couple of days to go back and look at the code again, but since the file names and function names are available it would be easy for interested parties to check.

de0u

Watermelon I checked the file you mentioned. I found a spelling mistake in the source code [...]

LOL, and it appears some IDE happily amplified the mistake.