OvmfPkg: allocate the EFI memory map for Linux as Loader Data

In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services()
expect that whoever allocates the EFI memmap allocates it in Loader Data
type memory. Linux's own exit_boot()-->low_alloc() complies, but
SetupLinuxMemmap() in LoadLinuxLib doesn't.

The memory type discrepancy leads to efi_memblock_x86_reserve_range() and
efi_reserve_boot_services() both trying to reserve the range backing the
memmap, resulting in memmap entry truncation in
efi_reserve_boot_services().

This fix also makes this allocation consistent with all other persistent
allocations in  "OvmfPkg/Library/LoadLinuxLib/Linux.c".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/SecureBootConfigDxe: Avoid illegal access

When enrolling the certificate from a file, the suffix check function
check the last 4 characters to filter out non-DER files. However,
if the length of the file name is less than 4, the address prior to
the file name will be accessed while it shouldn't. This commit checks
the length of the file name to avoid illegal access.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14556 6f19259b-4bc3-4df7-8a09-765794883524