Skip to content
Snippets Groups Projects
  • View options
  • View options
  • Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    • David Runge marked this issue as blocked by #34 (closed)
      • David Runge
        Developer
      • Wiktor Kwapisiewicz
        Developer

        efi_signer is a good starting point. I've reviewed it some time ago and IIUC it uses picky crates to do the actual signing. Sadly picky just takes raw software keys and does the signing with them with no abstractions so to use NetHSM with that we'd need to upstream a couple of fixes. (just mentioning my experience)

      • David Runge
        Developer

        IIRC @foxboron also had some more insight on this topic and the integration with the shim build process (he was not a fan of the "build shim and sign the blob" approach, as it leads to not being bootable on some systems).

        Maybe he can provide some more feedback wrt the X.509 use and to what extend we would also need this in what capacity in kernel module signing.

      • Morten Linderud

        Please note that signing shim and kernel module signing is two different problems. shim is signed by Microsoft Authenticode which is a CMS/subset of PKCS7. KMS is kernel specific and I haven't looked at it for a while. I think it's plain PKCS7(?). I'll only be talking about shim in this case.

        I have some strong opinions on this. We should not be implementing the specifics of Microsoft Authenticode into signstar, and we should not be relying on poor projects with skectchy licenses that nobody is using (I'm looking at efi_signer). This is because we really do not want to be in the business of having to care about authenticode and future signstar authors would need to be familiar with the spec to maintain this project. I don't like that.

        My preferences is listen in order:

        1. pesign has a server mode with a client setup. Lets use this as this is what most distros, and other vendors, are using to do Microsoft Authenticode. I understand having this as native code is nice, and having a seperate C process is not great, but I would rather have a solution with existing buy-in from multiple vendors.

        2. The next best option is to use a library with existing buy-in from other distros. The only ones I know that cares about this in relation to Rust is NixOS people having worked on goblin. I don't think anyone is using this in production for anything, but we will have buy-in from other distros solving this problem in Rust. I have also reviewed the implementation once and I think this is the best native code option for rust.

        3. Lets shell out to something using my go-uefi library that meets some interface from signstar. Also boring but my Go implementation is probably the most widely deployed non-C implementation of Microsoft Authenticode at this point?

        I would need to read up again on how we should deal with kernel module signatures, but afaik it's a shell-script calling into openssl with signature files appended to the module.

        Edited by Morten Linderud
      • Wiktor Kwapisiewicz
        Developer

        FWIW I've got in touch with Arthur and he pointed me to https://github.com/nix-community/goblin-signing (which, contrary to its name, shouldn't be nix-specific).

      • Please register or sign in to reply
    • David Runge changed the description ·