UEFI Secure Boot Tools Updated for 2.4

UEFI 2.4 has been out for a while (18 months to be exact).  However, it’s taken me a while to redo the tianocore builds for the 2.4 base.  This is now done, so the OVMF packages are now building 2.4 roms


Please remember that this is bleeding edge.  I found a few bugs while testing the tools, so there are likely many more lurking in there.  I’ve also updated the tools package


As of version 1.5.1, there’s a new generator for hashed revocation certificates and KeyTool now supports the timestamp signature database.  I’ve also published a version of sbsigntools


Which, as of 0.7, has support for multiple signatures.

15 thoughts on “UEFI Secure Boot Tools Updated for 2.4

      1. David Mattli

        The “Additional terms” section at the bottom of the license seems to state that it can only be used to implement EFI/UEFI, such a restriction is probably a violation of the DFSG.

        1. jejb Post author

          If you compare the licence against DFSG: Section 3 says you must allow derivative works and modifications to be made and distributed under the same terms … the terms are they must be implementing UEFI, so that seems to be OK. Sections 5,6,8,9 prohibit certain effects of the terms, but implementing UEFI seems to be consistent with them all.

          1. David Mattli

            I would interpret

            “all derivative works thereof being used for and designed only to read
            and/or write to a file system that is directly managed by Intel’s
            Extensible Firmware Initiative (EFI) Specification”

            as discrimination against a field of endeavor, a violation of section 6.

          2. jejb Post author

            OK, so this is where we differ. A field of endeavour restriction to me means that you’re prohibited from using the work in a particular field of endeavour, like Banking or Rocketry or Nuclear science. A restriction to conform to a particular specification would only be a field of endeavour restriction if the specification itself had such a restriction. UEFI has no such restriction, so UEFI can be used in any field of endeavour.

          3. David Mattli

            I just forked it and I have modified it to not work with UEFI. Is that a violation of the license?

            If so, the license does not allow for modification.

            Also this part “and to create firmware, applications, utilities and/or drivers.” could be interpreted as restricting use.

          4. jejb Post author

            > I just forked it and I have modified it to not work with UEFI. Is that a violation of the license?

            Yes, because the licence says it must be implementing the UEFI spec so you modified it not in conformance with the licence.

            > If so, the license does not allow for modification.

            It doesn’t allow arbitrary modification (no licence actually does). However, DFSG 3 only requires modifications allowing redistribution under the licence. If you violate the licence to make the modification, then no, you can’t (in the same way you can’t modify a GPL programme and not provide the modified source).

            > Also this part “and to create firmware, applications, utilities and/or drivers.” could be interpreted as restricting use.

            Not really … it’s not a restriction. It’s actually a relaxation of the restriction on implementing UEFI specification.

            However, this is is really just splitting hairs. The real question is does a licence that allows modifications but requires you to implement a standard conform to the DFSG. I think it does because there’s no prohibition on this type of restriction in the clauses that try to regulate restrictions, but others may have different opinions.

          5. Aya

            By Karen 2013 年 03 月 22 日 – 22:18:41I have iMac 27 late 2009,mountain lion os. Try to install win7 via boot camp but fail beuscae the Mac cannot detect the windows installer disc. The win7 installer disc can be read in pc and the iMac DVD drive can read other disc.Pls advise, thanks

  1. Pingback: Las herramientas « UEFI Secure Boot Tools » han sido actualizadas a la versión 2.4 | Gustavo Pimentel's GNU/Linux Blog

  2. GS

    There appears to be a bug in the efitools 1.5.x timestamp month field for sign-efi-sig-list tool. The tool is currently generating month values in the range of 0 to 11 but the UEFI spec uses values 1-12. This causes a problem for January dates in particular because secure boot initialized with a month 0 key cannot be later appended or replaced (at least my AMI UEFI will not allow it). I think adding one to the timestamp.Month value (timestamp.Month = tm->tm_mon + 1;) should fix this.

    1. jejb Post author

      Yes, that’s a problem. I just put this fix for it into the repository. Hopefully that will fix the problem and I’ll do another release of the tools shortly.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.