1. 24 Jul, 2018 1 commit
  2. 15 Sep, 2017 1 commit
  3. 13 Sep, 2017 1 commit
  4. 29 Aug, 2017 1 commit
  5. 07 Aug, 2017 1 commit
  6. 22 Sep, 2016 1 commit
  7. 26 Jul, 2016 2 commits
  8. 09 Jun, 2016 1 commit
  9. 11 May, 2016 2 commits
  10. 22 Mar, 2016 1 commit
  11. 17 Nov, 2015 6 commits
    • Peter Jones's avatar
      shim: check for EFI\BOOT\BOOT${ARCH}.EFI as well as the leading \ version · 4d70bbd8
      Peter Jones authored
      I found a machine whose BDS gives us relative paths, yay!  The rest of
      the code still works without that leading slash, so just make it one
      more item we let through our StrnCaseCmp() filter.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      4d70bbd8
    • Peter Jones's avatar
      shim: fix resource leak on should_use_fallback() error path · b7e59fd9
      Peter Jones authored
      ExitBootServices() and Exit() should both clean these up anyway, but we
      should do the right thing nonetheless.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      b7e59fd9
    • Peter Jones's avatar
      shim: if generate_path() gets a full path, just return it. · 6d525899
      Peter Jones authored
      We decide if it's a full path by if it starts with \\EFI\\.  That's
      quite lazy, but we can't just check \\ like you'd hope, because we need
      to stay compatible with what we've set as DEFAULT_LOADER in the past,
      and I don't feel like writing the full path traversal file test.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      6d525899
    • Peter Jones's avatar
      shim: fix a wrong-abi call to Stall() and ResetSystem() · b0d44f44
      Peter Jones authored
      Woops.  The net outcome of these is going to be a sleep of unknown
      duration, followed by either a) ResetSystem() with some random selection
      of warm/cold boot, or b) ResetSystem() returning an error and shim
      returning error from efi_main().
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      b0d44f44
    • Peter Jones's avatar
      shim: handle BDS's li->LoadOptions and Shell's li->LoadOptions . · 07d5f970
      Peter Jones authored
      Load options are a giant pain in the ass, because the shell is a giant
      piece of junk.  If we're invoked from the EFI shell, we get something
      like this:
      
      00000000 5c 00 45 00 36 00 49 00 5c 00 66 00 65 00 64 00 |\.E.F.I.\.f.e.d.|
      00000010 6f 00 72 00 61 00 5c 00 73 00 68 00 69 00 6d 00 |o.r.a.\.s.h.i.m.|
      00000020 78 00 36 00 34 00 2e 00 64 00 66 00 69 00 20 00 |x.6.4...e.f.i. .|
      00000030 5c 00 45 00 46 00 49 00 5c 00 66 00 65 00 64 00 |\.E.F.I.\.f.e.d.|
      00000040 6f 00 72 00 61 00 5c 00 66 00 77 00 75 00 70 00 |o.r.a.\.f.w.u.p.|
      00000050 64 00 61 00 74 00 65 00 2e 00 65 00 66 00 20 00 |d.a.t.e.e.f.i. .|
      00000060 00 00 66 00 73 00 30 00 3a 00 5c 00 00 00       |..f.s.0.:.\...|
      
      which is just some paths rammed together separated by a UCS-2 NUL. But
      if we're invoked from BDS, we get something more like:
      
      00000000 01 00 00 00 62 00 4c 00 69 00 6e 00 75 00 78 00 |....b.L.i.n.u.x.|
      00000010 20 00 46 00 69 00 72 00 6d 00 77 00 61 00 72 00 | .F.i.r.m.w.a.r.|
      00000020 65 00 20 00 55 00 70 00 64 00 61 00 74 00 65 00 |e. .U.p.d.a.t.e.|
      00000030 72 00 00 00 40 01 2a 00 01 00 00 00 00 08 00 00 |r.....*.........|
      00000040 00 00 00 00 00 40 06 00 00 00 00 00 1a 9e 55 bf |.....@........U.|
      00000050 04 57 f2 4f b4 4a ed 26 4a 40 6a 94 02 02 04 04 |.W.O.:.&J@j.....|
      00000060 34 00 5c 00 45 00 46 00 49 00 5c 00 66 00 65 00 |4.\.E.F.I.f.e.d.|
      00000070 64 00 6f 00 72 00 61 00 5c 00 73 00 68 00 69 00 |o.r.a.\.s.h.i.m.|
      00000080 6d 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 |x.6.4...e.f.i...|
      00000090 00 00 7f ff 40 00 20 00 5c 00 66 00 77 00 75 00 |...... .\.f.w.u.|
      000000a0 70 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 |p.x.6.4...e.f.i.|
      000000b0 00 00                                           |..|
      
      which is clearly an EFI_LOAD_OPTION filled in halfway reasonably.  In
      short, the UEFI shell is still a useless piece of junk.
      
      So anyway, try to determine which one we've got and handle it
      appropriately.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      07d5f970
    • Peter Jones's avatar
      82e8358f
  12. 30 Jun, 2015 1 commit
  13. 29 Jun, 2015 3 commits
  14. 16 Jun, 2015 4 commits
  15. 11 Jun, 2015 2 commits
  16. 04 Jun, 2015 1 commit
  17. 13 Apr, 2015 2 commits
    • Peter Jones's avatar
      Don't install our protocols if we're not in secure mode. · 8d535fc9
      Peter Jones authored
      System services haven't been hooked if we're not in secure mode, so
      do_exit() will never be called.  In this case shim never gets control
      once grub exits, which means if booting fails and the firmware tries
      another boot option, it'll attempt to talk to the shim protocol we
      installed.
      
      This is wrong, because it is allowed to have been cleared from ram at
      this time, since the task it's under has exited.
      
      So just don't install the protocols when we're not enforcing.
      
      This version also has a message and a 2-second stall after calling
      start_image(), so that we can tell if we are on the expected return path
      of our execution flow.
      8d535fc9
    • Peter Jones's avatar
      Align the sections we're loading, and check for validity /after/ discarding. · 96cf3c01
      Peter Jones authored
      Turns out a) the codegen on aarch64 generates code that has real
      alignment needs, and b) if we check the length of discardable sections
      before discarding them, we error for no reason.
      
      So do the error checking in the right order, and always enforce some
      alignment because we know we have to.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      96cf3c01
  18. 06 Oct, 2014 1 commit
  19. 02 Oct, 2014 2 commits
  20. 01 Oct, 2014 1 commit
  21. 21 Sep, 2014 4 commits
  22. 19 Sep, 2014 1 commit
    • Peter Jones's avatar
      Actually refer to the base relocation table of our loaded image. · 486bf03e
      Peter Jones authored
      Currently when we process base relocations, we get the correct Data
      Directory pointer from the headers (context->RelocDir), and that header
      has been copied into our pristine allocated image when we copied up to
      SizeOfHeaders.  But the data it points to has not been mirrored in to
      the new image, so it is whatever data AllocPool() gave us.
      
      This patch changes relocate_coff() to refer to the base relocation table
      from the image we loaded from disk, but apply the fixups to the new
      copy.
      
      I have no idea how x86_64 worked without this, but I can't make aarch64
      work without it.  I also don't know how Ard or Leif have seen aarch64
      work.  Maybe they haven't?  Leif indicated on irc that they may have
      only tested shim with simple "hello world" applications from gnu-efi;
      they are certainly much less complex than grub.efi, and are generated
      through a different linking process.
      
      My only theory is that we're getting recycled data there pretty reliably
      that just makes us /not/ process any relocations, but since our
      ImageBase is 0, and I don't think we ever load grub with 0 as its base
      virtual address, that doesn't follow.  I'm open to any other ideas
      anybody has.
      
      I do know that on x86_64 (and presumably aarch64 as well), we don't
      actually start seeing *symptoms* of this bug until the first chunk[0] of
      94c9a77f is applied[1].  Once that is applied, relocate_coff() starts
      seeing zero[2] for both RelocBase->VirtualAddress and
      RelocBase->SizeOfBlock, because RelocBase is a (generated, relative)
      pointer that only makes sense in the context of the original binary, not
      our partial copy.  Since RelocBase->SizeOfBlock is tested first,
      relocate_base() gives us "Reloc block size is invalid"[3] and returns
      EFI_UNSUPPORTED.  At that point shim exits with an error.
      
      [0] The second chunk of 94c9a77f patch makes no difference on this
          issue.
      [1] I don't see why at all.
      [2] Which could really be any value since it's AllocatePool() and not
          AllocateZeroPool() results, but 0 is all I've observed; I think
          AllocatePool() has simply never recycled any memory in my test
          cases.
      [3] which is silent because perror() tries to avoid talking because that
          has caused much crashing in the past; work needs to go in to 0.9 for
          this.
      Signed-off-by: 's avatarPeter Jones <pjones@redhat.com>
      486bf03e