Salt init_boot and vendor_boot using the build number

If you don't provide a salt, avbtool uses random bytes as the salt.
The randomness is bad for build caching and being able to diff
partitions to ensure code changes aren't breaking anything.

It's not exactly clear if the salt is necessary at all or not, but
as an intermediate step, salt the images using the build number instead
of purely random bytes.

I've only done the init_boot and vendor_boot partitions in this cl,
but I plan to expand it to all the other partitions. There are other
diffs besides the avb hash in those partitions right now though so it's
harder to test.

Bug: 380508890
Test: m soong_generated_init_boot_filesystem_test
Change-Id: I87afb2ef254fcdc981c72f107e94da34d1f07fb8

1 files changed, 8 insertions, 0 deletions

diff --git a/filesystem/bootimg.go b/filesystem/bootimg.go
index c8e27e5bc..0ffec2654 100644
--- a/filesystem/bootimg.go
+++ b/filesystem/bootimg.go
@@ -330,9 +330,17 @@ func (b *bootimg) addAvbFooter(ctx android.ModuleContext, unsignedImage android.
 		cmd.Flag("--dynamic_partition_size")
 	}
 
+	// If you don't provide a salt, avbtool will use random bytes for the salt.
+	// This is bad for determinism (cached builds and diff tests are affected), so instead,
+	// we try to provide a salt. The requirements for a salt are not very clear, one aspect of it
+	// is that if it's unpredictable, attackers trying to change the contents of a partition need
+	// to find a new hash collision every release, because the salt changed.
 	if kernel != nil {
 		cmd.Textf(`--salt $(sha256sum "%s" | cut -d " " -f 1)`, kernel.String())
 		cmd.Implicit(kernel)
+	} else {
+		cmd.Textf(`--salt $(sha256sum "%s" "%s" | cut -d " " -f 1 | tr -d '\n')`, ctx.Config().BuildNumberFile(ctx), ctx.Config().Getenv("BUILD_DATETIME_FILE"))
+		cmd.OrderOnly(ctx.Config().BuildNumberFile(ctx))
 	}
 
 	cmd.FlagWithArg("--partition_name ", b.bootImageType.String())