shim: ShimLock protocol uses "sysv64" function ABI

[josephlr]

See the systemd-boot declaration:
https://github.com/systemd/systemd/blob/5efbd0bf897a990ebe43d7dc69141d87c404ac9a/src/boot/efi/shim.c#L23-L31

This is because the shim is built with sysv ABI funcs by defualt.

This PR also adds bindings to the hashing functionality of the shim. For more information see:

• The shim's protocol declaration
• The shim's context declaration

Signed-off-by: Joe Richey joerichey@google.com

[josephlr]

CC: #226, @nicholasbishop

[nicholasbishop]

Thanks for the fix!

Are the hash/context methods useful for other bootloaders? I had sort of thought they were just used by MOK manager and so basically internal to shim. I took a quick look around Grub and only saw the verify method being called, but I might have missed something.

[josephlr]

they were just used by MOK manager and so basically internal to shim.

I'm not sure here. CC: @mjg59. Matthew, do you know if the non-verify methods of the Shim protocol are considered implementation details?

Are the hash/context methods useful for other bootloaders?

I can think of three uses:

• Doing something similar to the MOK manager. Taking an EFI Binary and computing its Authenticode hash for enrollment w/ EFI_SIGNATURE_LIST/EFI_SIGNATURE_DATA
• Some sort of boot-time Signer of EFI Binaries (which would require computing such a hash). However, most binaries would probably just do the parsing/hashing directly, as they might not be loaded by the SHIM.
• A second stage bootloader might have its own type of MokList or Internal Certificates, so it might want to verify a binary but against a different root of trust.

They would certainly see less use than the Verify method itself.

[nicholasbishop]

I verified that the Context struct matches up, and the new function pointers look correct to me other than my question about passing an array pointer. (I assume it's fine, since Rust knows array lengths at compile time it shouldn't be a fat pointer, but I don't know enough details to be sure.)

Maybe worth breaking this up into 3 PRs, one for each commit? Fixing the verify ABI seems uncontroversial, but I don't have enough knowledge to be sure about the rest.

[GabrielMajeri]

@nicholasbishop I think it's ok to keep it in the same PR. It's small enough to be manageable for review.

[josephlr]

@nicholasbishop I think it's ok to keep it in the same PR. It's small enough to be manageable for review.

@GabrielMajeri let me know if you thing this PR needs anything else.

they were just used by MOK manager and so basically internal to shim.

I'm not sure here. CC: @mjg59. Matthew, do you know if the non-verify methods of the Shim protocol are considered implementation details?

Given that the MokManager uses these methods, removing/changing them in the shim wouldn't be backwards compatible, as the shim and MokManger don't have to exactly match in version. So I think it should be fine to rely on these two methods.

[GabrielMajeri]

Everything looks fine to me, I'm merging it