Ability to verify a binary that was built from source

[wessel-novacustom]

The problem you're addressing (if any)

Users may want to reflash their firmware by building it from source and to flash it either internally or even better: externally. This is already possible.

As an extra security layer, to make sure that the built firmware binary hasn't been tampered with or corrupted, it would be nice if the user can verify the sha256 hash of the binary they have built with the sha256 hash of the publicly available binary.

Currently, the sha256 hash of a custom built version differs, because the public binaries that Dasharo publishes are signed with private vboot keys.

Describe the solution you'd like

The expected sha256sum hash value when building from source should be published alongside the binaries that were published with private vboot keys.

Where is the value to a user, and who might that user be?

Users will have an additional security layer to make sure that the firmware they have built from source corresponds with what the Dasharo firmware team knows as being genuine and untouched.

Describe alternatives you've considered

No response

Additional context

Please join the discussion here if you have any thoughts on this topic.

[pietrushnic]

@wessel-novacustom, what binaries are you referring to? I have a feeling we cannot meet those expectations if we talking about Dasharo Entry Subscription.

The expected sha256sum hash value when building from source should be published alongside the binaries that were published with private vboot keys.

This essentially means scope creep on our side because we would have to build with some publicly available keys. Binaries would not be published. First, those provide zero security since keys are public, and second, the point of the Dasharo (coreboot+Heads) Entry Subscription is to deliver binaries, so those cannot be published since that product would partially lose sense and value. We did the publication of hashes for binaries built with developer keys in the past: https://docs.dasharo.com/variants/msi_z690/releases/#v113-2024-01-22. What may make sense in some context, but we should agree on what is the real problem here.

Maybe I misunderstood something, so please clarify if you mean: https://docs.dasharo.com/variants/novacustom_nv4x_adl/heads/#v090-2024-02-29

[wessel-novacustom]

@pietrushnic

I didn't necessarily mean a DES release, actually. Could be any release.

Maybe the goal is not clear. The goal we would like to accomplish is to give the user the assurance that the firmware they built from source is valid and genuine.

Is that possible?

[pietrushnic]

@wessel-novacustom goal is clear, but depending on the type of release, it is achieved in different ways, so we have to be precise about which type of release we have in mind. So, for clarity, let's assume we are talking about NovaCustom public releases as part of the Dasharo Support Package, e.g. here.

That goal would be achieved by publishing binaries and hashes for binaries signed with publicly available developer keys. Since developer keys are public, those binaries would have no security properties. What can be done with those binaries and hashes is proof that those have been built from the given source code.

The problem is how you can trust binaries published by 3mdeb and signed with a not available key. This cannot be done without either:

• redesign of coreboot, so vboot would behave in a different way - very unlikely since Google is one of the decision-makers and users of that feature,
• resigning from using vboot and using CBFS verification - it was suggested by @miczyg1, but we would like first check documentation how it works before proceeding
• create some hacky scripts, which extract signatures from binaries, so those could be compared between each other (3mdeb signed vs 3mdeb dev signed) - this is probably bad option for long term

So this feature is not that simple because of the design decisions behind vboot. OTOH vboot caused so much trouble for us in the past that switching to CBFS verification is an option that appeals to the Dasharo Team.

[wessel-novacustom]

@pietrushnic Ah okay, I thought it would have been as easy as adding another SHA256 hash file to the Binaries section with some short explanation about the difference between that file and the signed binary files.

[mkopec]

create some hacky scripts, which extract signatures from binaries, so those could be compared between each other (3mdeb signed vs 3mdeb dev signed) - this is probably bad option for long term

I actually this this may work well. We could for example have digests for each FMAP region and compare them separately. A dev signed binary and a prod signed binary should have identical regions containing code, only the Vboot regions would change.

This way we could also compare clean binaries with code dumped from a machine (with EFI vars popuplated, ME region changed etc)

[wessel-novacustom]

create some hacky scripts, which extract signatures from binaries, so those could be compared between each other (3mdeb signed vs 3mdeb dev signed) - this is probably bad option for long term

I actually this this may work well. We could for example have digests for each FMAP region and compare them separately. A dev signed binary and a prod signed binary should have identical regions containing code, only the Vboot regions would change.

This way we could also compare clean binaries with code dumped from a machine (with EFI vars popuplated, ME region changed etc)

@macpijan We should work on that soon, it would be nice if this could be planned.

[miczyg1]

create some hacky scripts, which extract signatures from binaries, so those could be compared between each other (3mdeb signed vs 3mdeb dev signed) - this is probably bad option for long term

I actually this this may work well. We could for example have digests for each FMAP region and compare them separately. A dev signed binary and a prod signed binary should have identical regions containing code, only the Vboot regions would change.

Just replace VBLOCK and GBB regions, and that's it. A few cbfstool commands, nothing too complex.

This way we could also compare clean binaries with code dumped from a machine (with EFI vars popuplated, ME region changed etc)

Well, of course you may do that if you exclude the ME, SMMSTORE and MRC_CACHE regions...

[mkopec]

I've started work on a tool for comparing coreboot binaries here: https://github.com/Dasharo/romscope