1. 24 Jul, 2018 1 commit
  2. 29 Sep, 2017 2 commits
  3. 27 Sep, 2017 1 commit
  4. 15 Sep, 2017 1 commit
  5. 13 Sep, 2017 1 commit
  6. 29 Aug, 2017 1 commit
  7. 07 Aug, 2017 1 commit
  8. 22 Sep, 2016 1 commit
  9. 26 Jul, 2016 3 commits
  10. 18 May, 2016 1 commit
    • Peter Jones's avatar
      Work around binutils version string weirdness. · 08ede98f
      Peter Jones authored
      Nick Clifton wrote to me and explained:
      
      Subject: SHIM - objcopy version check broken by RHEL 7.3 binutils
      Hi Peter,
      
        We (the tools group) have run across a small problem with the shim
        package for RHEL 7.3, whilst testing out a new version of the
        binutils.  It complains that it needs a version of objcopy that is
        >= 2.23, despite the fact that the version is actually 2.25.1.
      
        I tracked the problem down to an extraneous space at the end of the
        version string being produced by objcopy:
      
          "GNU objcopy version 2.25.1-8.el7 "
      
        The Makefile in the shim package uses this rule to test the version of
        objcopy:
      
          OBJCOPY_GTE224  = $(shell expr `$(OBJCOPY) --version |grep ^"GNU objcopy" | sed 's/^.* //g' | cut -f1-2 -d.` \>= 2.24)
      
        But, because of that extra space, the sed expression clips the entire
        line and so the test fails.
      
        The extra space is there because normally the version number would be
        followed by a date.  For example:
      
          "GNU objcopy version 2.23.52.0.1-56.el7 20130226"
      
        So in this case the sed will extract the date, not the version number,
        but the test will still pass.
      
        I could fix the binutils to remove the space, although it would be a
        bit messy and it would not fix the problem when a date is appended to
        the version number.  Instead, I would like to propose a small patch to
        the shim Makefile.  If you change the line to:
      
          OBJCOPY_GTE224  = $(shell expr `$(OBJCOPY) --version |grep ^"GNU objcopy" | sed 's/^.version //g' | cut -f1-2 -d.` \>= 2.24)
      
        then the test will work as intended, with or without an extra space at
        the end of the version and with or without a date appended.
      
        Would it be possible to have this change added to the shim package ?
      
      Cheers
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      08ede98f
  11. 11 May, 2016 1 commit
    • Matthew Garrett's avatar
      Measure state and second stage into TPM · 964f56b3
      Matthew Garrett authored
      Add support for measuring the MOK database and secure boot state into a
      TPM, and do the same for the second stage loader. This avoids a hole in
      TPM measurement between the firmware and the second stage loader.
      964f56b3
  12. 17 Nov, 2015 1 commit
  13. 09 Nov, 2015 1 commit
    • Gary Ching-Pang Lin's avatar
      Cryptlib: Define the va functions for EFIAPI · 775fdb9f
      Gary Ching-Pang Lin authored
      It turned out that my previous crash fix(*) was wrong.
      We actually always used the gcc built-in va functions instead of
      the "real" va functions for EFIAPI, and we are just lucky that
      ERR_add_error_data didn't crash before.
      
      This commit copies the va functions from MdePkg/Include/Base.h
      in edk2 and introdues NO_BUILTIN_VA_FUNCS for x86_64, so that all
      the x86_64 build will adopt the new va functions. For safety,
      I also added EFIAPI to all the functions which use va_* to avoid
      the potential trouble.
      
      (*) a7f4b26cSigned-off-by: 's avatarGary Ching-Pang Lin <glin@suse.com>
      775fdb9f
  14. 18 Sep, 2015 1 commit
  15. 28 Jul, 2015 1 commit
  16. 30 Jun, 2015 3 commits
  17. 29 Jun, 2015 1 commit
  18. 13 May, 2015 2 commits
  19. 12 May, 2015 1 commit
  20. 10 May, 2015 1 commit
  21. 06 May, 2015 1 commit
  22. 15 Apr, 2015 1 commit
  23. 13 Apr, 2015 2 commits
  24. 13 Oct, 2014 1 commit
  25. 06 Oct, 2014 1 commit
  26. 02 Oct, 2014 1 commit
  27. 01 Oct, 2014 1 commit
  28. 21 Sep, 2014 2 commits
    • Peter Jones's avatar
      Do the same for ia32... · f9d825b2
      Peter Jones authored
      Once again, on ia32 this time, we see:
      
      00000120  47 84 00 00 0a 00 00 00  00 00 00 00 00 00 00 00 |G...............|
      
      Which is where the pointer on ia32 for the Base Relocation Table should
      be.  It points to 0x8447, which isn't a particularly reasonable address as
      numbers go, and happens to have this data there:
      
      00008440  6f 00 6e 00 66 00 69 00  67 00 75 00 72 00 65 00 |o.n.f.i.g.u.r.e.|
      00008450  00 00 49 00 50 00 76 00  36 00 28 00 00 00 2c 00 |..I.P.v.6.(...,.|
      00008460  25 00 73 00 2c 00 00 00  29 00 00 00 25 00 64 00 |%.s.,...)...%.d.|
      00008470  2e 00 25 00 64 00 2e 00  25 00 64 00 2e 00 25 00 |..%.d...%.d...%.|
      00008480  64 00 00 00 44 00 48 00  43 00 50 00 00 00 49 00 |d...D.H.C.P...I.|
      00008490  50 00 76 00 34 00 28 00  00 00 2c 00 25 00 73 00 |P.v.4.(...,.%.s.|
      
      And so that table is, in theory, this part:
      
      00008447                       00  67 00 75 00 72 00 65 00 |       .g.u.r.e.|
      00008450  00                                               |.               |
      
      Which is pretty clearly not a pointer table of any kind.
      
      So give ia32 the same treatment as x86_64, and now all arches work basically
      the same.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      f9d825b2
    • Peter Jones's avatar
      Generate a sane PE header on shim, fallback, and MokManager. · 2c59a1a0
      Peter Jones authored
      It turns out a7249a65 was masking a second problem - on some binaries,
      when we actually don't have any base relocations at all, binutils'
      "objcopy --target efi-app-x86_64" is generating a PE header with a base
      relocations pointer that happily points into the middle of our text
      section.  So with shim processing base relocations correctly, it refuses
      to load those binaries.
      
      For example, on one binary I just built:
      
      00000130  00 a0 00 00 0a 00 00 00  00 00 00 00 00 00 00 00 |................|
      
      which says there's a Base Relocation Table at 0xa000 that's 0xa bytes long.
      That's here:
      
      0000a000  58 00 29 00 00 00 00 00  48 00 44 00 28 00 50 00 |X.).....H.D.(.P.|
      0000a010  61 00 72 00 74 00 25 00  64 00 2c 00 53 00 69 00 |a.r.t.%.d.,.S.i.|
      0000a020  67 00 25 00 67 00 29 00  00 00 00 00 00 00 00 00 |g.%.g.).........|
      0000a030  48 00 44 00 28 00 50 00  61 00 72 00 74 00 25 00 |H.D.(.P.a.r.t.%.|
      
      So the table is:
      
      0000a000  58 00 29 00 00 00 00 00  48 00                   |X.).....H.      |
      
      That wouldn't be so bad, except those binaries are MokManager.efi,
      fallback.efi, and shim.efi, and sometimes they're .reloc, which we're
      actually trying to handle correctly now because grub builds with a real
      and valid .reloc table.  So though I didn't think there was any hair
      left on this yak, more shaving ensues.
      
      With this change, instead of letting objcopy do whatever it likes, we
      switch to "-O binary" and merely link in a header that's appropriate for
      our binaries.  This is the same method Ard wrote for aarch64, and it
      seems to work fine in either place (modulo some minor changes.)
      
      At some point this should be merged into gnu-efi instead of carrying our
      own crt0-efi-x86_64.S, but that's a less immediate problem.
      
      I did not need this problem.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      2c59a1a0
  29. 12 Aug, 2014 3 commits
  30. 25 Jun, 2014 1 commit