Age | Commit message (Collapse) | Author |
|
Update changelog entries/changes from Debian for 0.9+1474479173.6c180c6-1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Update Standards-Version.
* Embed the newly-minted Debian CA certificate.
* Vendorize debian/rules so that the same package can be used in both
Debian and Ubuntu without modification.
* Fix debian/copyright to match the spec (last match wins, not first)
* Fix shim.efi to not be executable.
* Add watchfile.
* Support parallel builds, because eh why not
* Update Vcs-Bzr.
|
|
file to properly pick up shim (shim$arch), MokManager (mm$arch), and
fallback (fb$arch).
|
|
* debian/patches/binutils-version-matching: dropped, fixed upstream.
|
|
|
|
|
|
* debian/copyright: add OpenSSL license
[ Mathieu Trudel-Lapierre ]
* debian/copyright: patches should be BSD, like the rest of the upstream
code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* debian/patches/binutils-version-matching: revert d9a4c912 to correctly
match objcopy's version on Ubuntu.
|
|
|
|
|
|
- Remaining patches:
+ second-stage-path
+ sbsigntool-not-pesign
|
|
|
|
|
|
|
|
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: Peter Jones <pjones@redhat.com>
|
|
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.
|
|
The second stage set is not working after commit
3322257e611e2000f79726d295bb4845bbe449e7 for those which load option
only have one string.
Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
|
|
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
ExitBootServices() and Exit() should both clean these up anyway, but we
should do the right thing nonetheless.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
This is mostly for debugging, so it's not a real problem if it's not
used right now. I just like having it handy.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
My favorite part of -Wsign-compare is how it shows different results on
different arches for no obvious reason.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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.
(*) a7f4b26cc35204165bd04e75c34e8e7aa2a87ecc
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
Building 0.9 with GNU Make 4.0 fails with the following error:
Makefile:4: *** Recursive variable 'RELEASE' references itself (eventually). Stop.
Change RELEASE to simply-expanded.
Signed-off-by: Linn Crosetto <linn@hpe.com>
|
|
According to the gcc5 porting guideline (*), gcc5 defaults to
-std=gnu11 instead of -std=gnu89. Append -std=gnu89 to CFLAGS
to avoid the potential problems.
(*) https://gcc.gnu.org/gcc-5/porting_to.html
Based on the patch from Cristian Rodriguez <crrodriguez@opensuse.org>
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
Without declaring EFIAPI for ERR_add_error_vdata, shim would crash
while verifying the loaded image.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
Also update Cryptlib to edk2 r17731
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|