Desync between stub hashes and actual hashes due to non-reproducibility #68

New issue

Closed

opened 2023-01-17 14:57:23 +00:00 by RaitoBezarius · 4 comments

RaitoBezarius commented

2023-01-17 14:57:23 +00:00

(Migrated from github.com)

Supposedly, given a (kernel, initrd), we generate a stub with the kernelh and initrdh corresponding.

The issue is that if we regenerate those files, if they are not reproducible, we have no guarantee the hash will be the same unfortunately.

We should try actively to detect those situations and update the stub hashes.

Supposedly, given a (kernel, initrd), we generate a stub with the kernelh and initrdh corresponding. The issue is that if we regenerate those files, if they are not reproducible, we have no guarantee the hash will be the same unfortunately. We should try actively to detect those situations and update the stub hashes.

nikstur commented

2023-01-17 20:08:46 +00:00

(Migrated from github.com)

Blindly updating the stub hashes poses a potential vulnerability IMO.

Maybe, we can somehow identify broken generations and try to regenerate them (i.e. regenerate stub, kernel, initrd together). Although, this means that other generations that worked before but point at the same kernel/initrd are now suddenly broken.

There might also be some weird interactions with appending secrets to an initrd.

Blindly updating the stub hashes poses a potential vulnerability IMO. Maybe, we can somehow identify broken generations and try to regenerate them (i.e. regenerate stub, kernel, initrd together). Although, this means that other generations that worked before but point at the same kernel/initrd are now suddenly broken. There might also be some weird interactions with appending secrets to an initrd.

👍 2

nikstur commented

2023-02-12 15:37:31 +00:00

(Migrated from github.com)

Now that I have thought about this in more detail, I have realized that this was actually never an issue. We never overwrite a (kernel, initrd, stub) path if it already exists and always use the hash of the file that is already on the ESP. So even if e.g. the kernel is not reproducible we would not know/care because it would just not be copied to the ESP and the kernelh in the stub would be retrieved from the already existing file on the ESP.

Now that I have thought about this in more detail, I have realized that this was actually never an issue. We never overwrite a (kernel, initrd, stub) path if it already exists and always use the hash of the file that is already on the ESP. So even if e.g. the kernel is not reproducible we would not know/care because it would just not be copied to the ESP and the `kernelh` in the stub would be retrieved from the already existing file on the ESP.

RaitoBezarius commented

2023-02-12 15:48:16 +00:00

(Migrated from github.com)

Now that I have thought about this in more detail, I have realized that this was actually never an issue. We never overwrite a (kernel, initrd, stub) path if it already exists and always use the hash of the file that is already on the ESP. So even if e.g. the kernel is not reproducible we would not know/care because it would just not be copied to the ESP and the kernelh in the stub would be retrieved from the already existing file on the ESP.

That's true as long as we do not interrupt lanzatool I think?

> Now that I have thought about this in more detail, I have realized that this was actually never an issue. We never overwrite a (kernel, initrd, stub) path if it already exists and always use the hash of the file that is already on the ESP. So even if e.g. the kernel is not reproducible we would not know/care because it would just not be copied to the ESP and the `kernelh` in the stub would be retrieved from the already existing file on the ESP. That's true as long as we do not interrupt lanzatool I think?

nikstur commented

2023-02-12 15:58:20 +00:00

(Migrated from github.com)

That is a general problem with not overwriting files if anything at that path exists, but is not specific to reproducibility. We can open a separate issue.

👍 1