The LzmaUefiDecompressGetInfo() function
[MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaDecompress.c] currently
silently truncates the UINT64 "DecodedSize" property of the compressed
blob to the UINT32 "DestinationSize" output parameter.
If "DecodedSize" is 0x1_0000_0100, for example, then the subsequent memory
allocation (for decompression) will likely succeed (allocating 0x100 bytes
only), but then the LzmaUefiDecompress() function (which re-fetches the
uncompressed buffer size from the same LZMA header into a "SizeT"
variable) will overwrite the buffer.
Catch (DecodedSize > MAX_UINT32) in LzmaUefiDecompressGetInfo() at once.
This should not be a practical limitation. (The issue cannot be fixed for
32-bit systems without spec modifications anyway, given that the
"OutputSize" output parameter of
EFI_GUIDED_SECTION_EXTRACTION_PROTOCOL.ExtractSection() has type UINTN,
not UINT64.)
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1816
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119115034.12897-2-lersek@redhat.com>
The BaseSerialPortLib16550 library does not implement
a constructor. This prevents the correct constructor
invocation order for dependent libraries.
e.g. A PlatformHookLib (for the Serial Port) may have
a dependency on retrieving data from a Hob. A Hob
library implementation may configure its initial state
in the HobLib constructor. Since BaseSerialPortLib16550
does not implement a constructor, the Basetools do not
resolve the correct order for constructor invocation.
To fix this, add an empty constructor to the serial port
library BaseSerialPortLib16550.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
UnicodeStrToAsciiStrS requires that the source string is shorter than
the destination buffer and will ASSERT if this is not true. Switch to
UnicodeStrnToAsciiStrS as there are cases where the source string is
longer than the buffer allocated for the device path.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2818
For better memory management, re-ordered the DestroyRamDisk and
ReportStatusCode calls inside the EfiBootManagerBoot() function.
This will help to clean the unused memory before reporting the
failure status, so that OEMs can use RSC Listener to launch
custom boot option or application for recovering the failed
hard drive.
This change will help to ensure that the allocated pool of memory
for the failed boot option is freed before executing OEM's RSC
listener callback to handle every boot option failure.
Signed-off-by: KrishnadasX Veliyathuparambil Prakashan <krishnadasx.veliyathuparambil.prakashan@intel.com>
Cc: "Gao, Zhichao" <zhichao.gao@intel.com>
Cc: "Ni, Ray" <ray.ni@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag
cleared. This means that the boot option should not be selected
by default, but it does not mean it should be omitted from the
boot selection presented by the boot manager: for this purpose,
another flag LOAD_OPTION_HIDDEN exists.
Given that the latter flag exists solely for the purpose of omitting
boot options from the boot selection menu, and LOAD_OPTION_XXX flags
can be combined if desired, hiding inactive boot options as well is
a mistake, and violates the intent of paragraph 3.1.3 of the UEFI
specification (revision 2.8 errata A). Let's fix this by dropping
the LOAD_OPTION_ACTIVE check from the code that populates the boot
selection menu.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The device manager UI library creates a UiApp submenu that contains a
list of network devices in the system. The logic that creates this menu
assumes that all handles have been connected to their drivers, but this
is not guaranteed in the general case: due to the way UiApp is constructed,
this logic runs before the UiApp entrypoint is invoked, which is where
ConnectAll() is normally called to ensure that all existing controllers
are connected to their drivers. Moving this call into DeviceManagerUiLib
is not an option, since it is incorporated into UiApp via NULL library
class resolution, and so it may not be included to begin with.
So work around this by doing an explicit additional ConnectAll() before
populating the pages.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Link: https://edk2.groups.io/g/devel/topic/72879609#57075
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2001
For S3BootScriptLib APIs:
S3BootScriptSaveIoWrite
S3BootScriptSaveMemWrite
S3BootScriptSavePciCfgWrite
S3BootScriptSavePciCfg2Write
S3BootScriptSaveSmbusExecute
S3BootScriptSaveInformation
S3BootScriptSaveInformationAsciiString
S3BootScriptLabel (happen in S3BootScriptLabelInternal())
possible numeric truncations will happen that may lead to S3 boot script
entry with improper size being returned to store the boot script data.
This commit will add checks to prevent this kind of issue.
Please note that the remaining S3BootScriptLib APIs:
S3BootScriptSaveIoReadWrite
S3BootScriptSaveMemReadWrite
S3BootScriptSavePciCfgReadWrite
S3BootScriptSavePciCfg2ReadWrite
S3BootScriptSaveStall
S3BootScriptSaveDispatch2
S3BootScriptSaveDispatch
S3BootScriptSaveMemPoll
S3BootScriptSaveIoPoll
S3BootScriptSavePciPoll
S3BootScriptSavePci2Poll
S3BootScriptCloseTable
S3BootScriptExecute
S3BootScriptMoveLastOpcode
S3BootScriptCompare
are not affected by such numeric truncation.
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Jian J Wang <jian.j.wang@intel.com>
Before writing data to FIFO, wait for the serial port to be ready,
to make sure both the transmit FIFO and shift register empty. Code
comment was saying the right thing but code was missing a check.
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
The LoadFile protocol can report such a large buffer size that we cannot
allocate enough reserved pages for. This particularly affects HTTP(S)
Boot, if the remote file is very large (for example, an ISO image).
While the TianoCore wiki mentions this at
<https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size>:
> The maximum RAM disk image size depends on how much continuous reserved
> memory block the platform could provide.
it's hard to remember; so log a DEBUG_ERROR message when the allocation
fails.
This patch produces error messages such as:
> UiApp:BmExpandLoadFile: failed to allocate reserved pages:
> BufferSize=4501536768
> LoadFile="PciRoot(0x0)/Pci(0x3,0x0)/MAC(5254001B103E,0x1)/
> IPv4(0.0.0.0,TCP,DHCP,192.168.124.106,192.168.124.1,255.255.255.0)/
> Dns(192.168.124.1)/
> Uri(https://ipv4-server/RHEL-7.7-20190723.1-Server-x86_64-dvd1.iso)"
> FilePath=""
(Manually rewrapped here for keeping PatchCheck.py happy.)
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.
The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().
In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.
It follows that the "DriverHandle" argument passed to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.
Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.
Therefore this patch addresses an actual bug.
The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.
Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
There is no sourceX offset in case when
Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor.
We are copying most left pixels instead of copying required rectangle.
Signed-off-by: Gris87 <Gris87@yandex.ru>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in UefiBootManagerLib which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in DxeCapsuleLibFmp which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
