| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The wildcard support was introduced in objcopy since binutils 2.24.
However, objcopy < 2.24 never issues any warning message with the
wildcard and a faulty binary will be generated. This commit makes
the build failed as a notification for the usage of binutils < 2.24.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
We depend on there being a .hash section in the binary, and that's not
the case on distributions that default to building with gnu-style ELF
hashes. Explicitly request sysv-style hashes in order to avoid building
broken binaries.
Signed-off-by: Matthew Garrett <mjg59@coreos.com>
|
|
Basically they messed around with stdarg some and now we need to do it
the other way.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
I'm going to have to fix any errors that have this anyway, so may as
well do it here properly.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Revert "Do the same for ia32..."
and "Generate a sane PE header on shim, fallback, and MokManager."
This reverts commit 6744a7ef8eca44948565c3d1244ec931ed3f6fee.
and commit 0e7ba5947eb38b79de2051ecf3b95055e620475c.
These are premature and I can do this without such drastic measures.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
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: Peter Jones <pjones@redhat.com>
|
|
This adds support for building the shim for a 32-bit ARM UEFI environment.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This adds support for building the shim for a 64-bit ARM UEFI environment.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This patch cleans up and refactors the Makefiles to better allow new
architectures to be added:
- remove unused Makefile definitions
- import Makefile definitions from top level rather than redefining
- move x86 specific CFLAGS to inside ifeq() blocks
- remove x86 inline asm
- allow $(FORMAT) to be overridden: this is necessary as there exists no
EFI or PE/COFF aware objcopy for ARM
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
If ca.crt was added into the certificate database, ca.crt would be the first
certificate in the signature. Because shim couldn't verify ca.crt with the
embedded shim.cer, it failed to load MokManager.efi.signed and
fallback.efi.signed.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
|
|
This adds additional bounds-checking on the section sizes. Also adds
-Wsign-compare to the Makefile and replaces some signed variables with
unsigned counteparts for robustness.
Signed-off-by: Kees Cook <kees@ubuntu.com>
|
|
Also removed unused LIB_PATH from some Makefiles.
Change-Id: I7d28d18f7531b51b6121a2ffb88bcaedec57c467
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
|
|
If these are overridden on the command line, pass them along to
the sub-makes.
Change-Id: I531ccb5d2f5e4be8e99d4892cdcfffffc1ad9877
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
|
|
Exposed during parallel builds
Change-Id: I9867858166dcafd69438f37ee5da14a267ace8f4
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
|
|
Do not use 0.6; on some machines it misunderstands the SetupMode
variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This reverts commit 21e40f0174814b3d91836e38c7cf95c8f2f1f3a4.
In principle I like the idea of what's going on here, but
generate_hash() really does need to have the expected result.
|
|
This adds additional bounds-checking on the section sizes. Also adds
-Wsign-compare to the Makefile and replaces some signed variables with
unsigned counteparts for robustness.
Signed-off-by: Kees Cook <kees@ubuntu.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
I feel dirty.
|
|
If we don't do this, an old key winds up being reused and
MokManager.efi.signed is signed with a different key than shim_cert
reflects.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Make OVERRIDE_SECURITY_POLICY a build option.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Since these are topically the same thing, they can live together.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
It works like this: during startup of shim, we hook into the system's
ExitBootServices() and StartImage(). If the system's StartImage() is
called, we automatically unhook, because we're chainloading to something
the system can verify.
When shim's verify is called, we record what kind of certificate the
image was verified against. If the call /succeeds/, we remove our
hooks.
If ExitBootServices() is called, we check how the bootloader verified
whatever it is loading. If it was verified by its hash, we unhook
everything and call the system's EBS(). If it was verified by
certificate, we check if it has called shim_verify(). If it has, we
unhook everything and call the system's EBS()
If the bootloader has not verified anything, and is itself verified by
a certificate, we display a security violation warning and halt the
machine.
|
|
This moves them both to be computed at runtime from a pointer+offset
rather than just a pointer, so that their real address can be entirely
derived from the section they're in.
This means you can replace the whole .vendor_cert section with a new one
with certs that don't have the same size.
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Conflicts:
shim.c
|
|
Conflicts:
Makefile
|
|
Basically, if you don't want grub.efi, you do:
make 'DEFAULT_LOADER=\\\\grubx64.efi'
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Conflicts:
Makefile
|
|
The password format is introduced for the password hash generated by crypt(),
so that the user can import the password hash from /etc/shadow. The packager,
especially those who packages 3rd party drivers, can utilize this feature to
import a 3rd party certificate without interfering the package installation.
This commit implements the sha256-based crypt() hash function.
Conflicts:
Makefile
MokManager.c
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
This is the first stage of porting the MokManager UI to the UI code used
by the Linux Foundation UEFI loader.
|
|
Without this patch, on some machines we never see MokManager's UI. This
protocol has never (I think?) been officially published, and yet I still
have new hardware that needs it.
If you're looking for a reference, look at:
EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl/ConsoleControl.c
in the edk2 tree from Tiano.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
Since I've finally merged in the "sections" branch, best to increment
the version number.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
With this change, the embedded certificate and dbx lists (vendor_cert,
vendor_cert_size, vendor_dbx, and vendor_dbx_size) wind up being in a
section named .vendor_cert, and so will look something like:
------
fenchurch:~/devel/github.com/shim$ objdump -h shim.efi
shim.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .eh_frame 000174a8 0000000000005000 0000000000005000 00000400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 000aa7e1 000000000001d000 000000000001d000 00017a00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .reloc 0000000a 00000000000c8000 00000000000c8000 000c2200 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data 00031228 00000000000c9000 00000000000c9000 000c2400 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .vendor_cert 00000375 00000000000fb000 00000000000fb000 000f3800 2**0
CONTENTS, READONLY
5 .dynamic 000000f0 00000000000fc000 00000000000fc000 000f3c00 2**3
CONTENTS, ALLOC, LOAD, DATA
6 .rela 0002afa8 00000000000fd000 00000000000fd000 000f3e00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .dynsym 0000f1f8 0000000000128000 0000000000128000 0011ee00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
------
This simplifies a security audit, because it means that different
versions of shim with substantially the same code with different keys
will be more easily comperable, and therefore logic differences may be
more easily identified.
This also means that if there's a trusted build you want to use, you can
remove the certificates, implant new ones, and have it signed, and the
code sections won't change.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
GCC 4.8.0 will try to use these by default, and you'll wind up looping
across the (uninitialized!) trap handler for uninitialized instructions.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
