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>
|
|
|
|
|
|
|
|
|
|
- Remove the vestigial FIPS stuff from upstream
- Make the fips module honor all the stuff we turn off.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The current code is incorrectly failing to load the fbaa64.efi image found
in Arm servers even though the UEFI shell code is able to properly load
and execute the same image.
The problem is due to the presence of a section header that has zero size
and address and marked "discardable" in the fbaa64.efi image.
Although there is already a check further down in the code to look for
the discardable bit and skip further verification checks if set, we never
get to that point due to the "end < base" check at the start of the loop.
Here is a dump of the fbaa64.efi image as compiled on an Arm machine
from the latest code in this repo:
% # First I used hexedit to change header byte from 'AA' to '86'
% # so that objdump was able to correctly parse the file:
% objdump -x -m aarch64 fbaa64.efi
fbaa64.efi: file format pei-x86-64
fbaa64.efi
architecture: i386:x86-64, flags 0x00000103:
HAS_RELOC, EXEC_P, D_PAGED
start address 0x0000000000000148
Characteristics 0x20e
executable
line numbers stripped
symbols stripped
debugging information removed
Time/Date Wed Dec 31 16:00:00 1969
Magic 020b (PE32+)
MajorLinkerVersion 2
MinorLinkerVersion 20
SizeOfCode 000b15d0
SizeOfInitializedData 00000000
SizeOfUninitializedData 00000000
AddressOfEntryPoint 0000000000000148
BaseOfCode 0000000000000148
ImageBase 0000000000000000
SectionAlignment 0000000000000020
FileAlignment 0000000000000008
MajorOSystemVersion 0
MinorOSystemVersion 0
MajorImageVersion 0
MinorImageVersion 0
MajorSubsystemVersion 0
MinorSubsystemVersion 0
Win32Version 00000000
SizeOfImage 000b1718
SizeOfHeaders 00000148
CheckSum 00000000
Subsystem 0000000a (EFI application)
DllCharacteristics 00000000
SizeOfStackReserve 0000000000000000
SizeOfStackCommit 0000000000000000
SizeOfHeapReserve 0000000000000000
SizeOfHeapCommit 0000000000000000
LoaderFlags 00000000
NumberOfRvaAndSizes 00000006
The Data Directory
Entry 0 0000000000000000 00000000 Export Directory [.edata (or where ever we found it)]
Entry 1 0000000000000000 00000000 Import Directory [parts of .idata]
Entry 2 0000000000000000 00000000 Resource Directory [.rsrc]
Entry 3 0000000000000000 00000000 Exception Directory [.pdata]
Entry 4 0000000000000000 00000000 Security Directory
Entry 5 0000000000000000 00000000 Base Relocation Directory [.reloc]
Entry 6 0000000000000000 00000000 Debug Directory
Entry 7 0000000000000000 00000000 Description Directory
Entry 8 0000000000000000 00000000 Special Directory
Entry 9 0000000000000000 00000000 Thread Storage Directory [.tls]
Entry a 0000000000000000 00000000 Load Configuration Directory
Entry b 0000000000000000 00000000 Bound Import Directory
Entry c 0000000000000000 00000000 Import Address Table Directory
Entry d 0000000000000000 00000000 Delay Import Directory
Entry e 0000000000000000 00000000 CLR Runtime Header
Entry f 0000000000000000 00000000 Reserved
Sections:
Idx Name Size VMA LMA File off Algn
0 .reloc 00000000 0000000000000000 0000000000000000 00000000 2**0
ALLOC, LOAD, READONLY, DATA
1 .text 000b15d0 0000000000000148 0000000000000148 00000148 2**4
CONTENTS, ALLOC, LOAD, CODE
SYMBOL TABLE:
no symbols
Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Aaron Young <aaron.young@oracle.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
|
|
When shim is invoked from a relative path (e.g: from the UEFI shell), the
Loaded Image handle LoadOptions can be set to the binary relative path.
But the is_our_path() function only checks if LoadOptions is set to the
absolute path of shim to ignore it. So if a relative path is there, shim
would set itself as the secondary loader and invoke itself in a loop.
To prevent that, use the path in LoadOptions to calculate the absolute
path and compare it with the one in the Loader Image handle FilePath.
Resolves: bz#1622485
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maran Wilson maran.wilson@oracle.com
Tested-by: Maran Wilson maran.wilson@oracle.com
|
|
The generate_path_from_image_path() doesn't properly handle the case when
shim is invoked using a relative path (e.g: from the EFI shell). In that
function, always the last component is stripped from absolute file path
to calculate the dirname, and this is concatenated with the image path.
But if the path is a relative one, the function will wrongly concatenate
the dirname with the relative image path, i.e:
Shell> FS0:
FS0:\> cd EFI
FS0:\EFI\> BOOT\BOOTX64.EFI
Failed to open \EFI\BOOT\BOOT\BOOTX64.EFI - Not found
Failed to load image \EFI\BOOT\BOOT\BOOTX64.EFI: Not found
start_image() returned Not found
Calculate the image path basename and concatenate that with the dirname.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maran Wilson maran.wilson@oracle.com
Tested-by: Maran Wilson maran.wilson@oracle.com
|
|
In Ubuntu 14.04, the following code in old Makefile:
mkdir -p Cryptlib/{Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}
will create a directory named "{Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}".
Signed-off-by: Ming Tan <ming.tan@intel.com>
|
|
builds'
|
|
When OpenSSL 1.1.0e didn't work so well, we added a macro for abort() to
passify the build. Now that we've got 1.1.0e in again, that macro
messes up building SysCall/CrtWrapper.c. This patch gets rid of the
macro.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
After verifying the image, a warning will show if the less strict CA
check is used.
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Also add the workaround patch so we won't lose it for the future update.
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Since openssl < 1.1.0 didn't check the x509 v3 extension strictly, a CA
certificate without the CA flag in the basic constraints or KeyCertSign
in the key usage was still loaded to verify EFI images.
We relax the check for now. In the future, the workaround should be
removed.
Signed-off-by: Gary Lin <glin@suse.com>
|
|
CryptPem only provides one function: RsaGetPrivateKeyFromPem(). Since we
don't need to retrieve any private key, it's safe to disable the
function.
Signed-off-by: Gary Lin <glin@suse.com>
|
|
X509_get_notBefore -> X509_getm_notBefore
X509_get_notAfter -> X509_getm_notAfter
Signed-off-by: Gary Lin <glin@suse.com>
|
|
- Remove the obsolete OBJ_cleanup()
- Update ossl_malloc() and ossl_free() due to the change of definition
of CRYPTO_set_mem_functions()
- Include stdarg.h earlier to avoid redefining VA_LIST
Signed-off-by: Gary Lin <glin@suse.com>
|
|
- Delete the old openssl files and use the script to copy the new files
- Add "-DNO_SYSLOG" to CFLAGS and add crypto/include to the include path
Signed-off-by: Gary Lin <glin@suse.com>
|
|
- Update update.sh to copy the openssl 1.1.0 source files
- Refresh the supplemental patch to reflect the change
- Add a patch for pk7_smime.c (*)
* aaf8049c3995dd2c0c42087a601c262545f36b9c
Fix a missing OpenSSL error message point
Signed-off-by: Gary Lin <glin@suse.com>
|
|
- Update to edk2 commit 7c410b3d4180087020c7734bf67cdc4ad9fdb136
CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
- Update headers in Cryptlib/Include/openssl/ to 1.1.0e
+ Also copy the openssl internal headers
Signed-off-by: Gary Lin <glin@suse.com>
|
|
- Remove the openssl version from update.sh since edk2 doesn't use the
version number in the directory name anymore.
- Refresh Cryptlib.diff to reflect the change
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Edk2 renamed OpenSslSupport.h, so we have to follow the change.
Also merge some changes from edk2 CrtLibSupport.h
Signed-off-by: Gary Lin <glin@suse.com>
|
|
This didn't seem to get documented anywhere, and this is as good a place as any.
|
|
Knowing the value of the reloc directory size is helpful for debugging,
cf. issue #131 [1],
[1]: https://github.com/rhboot/shim/issues/131
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
|
|
When writing MokList with EFI_VARIABLE_APPEND_WRITE, some HP laptops
may just return EFI_SUCCESS without writing the content into the flash,
so we have no way to detect if MokList is updated or not. Now we always
read MokList first and write it back with the new content.
https://github.com/rhboot/shim/issues/105
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Signed-off-by: Gary Lin <glin@suse.com>
|
|
|
|
Signed-off-by: Gary Lin <glin@suse.com>
|