This patch is to remove some redundant DEBUG output in SNP transmit function.
In case of return EFI_NOT_READY in PxeTransmit, the SNP driver is indicate
the caller that the transmit queue is full, it's a very common situation druing
transmit, not a critical error. So the patch move the DEBUG lever to EFI_D_NET.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=725
Historically many drives or medias do not correctly return their value
for block N - which is also referred as last addressable/recorded block.
When they do so, there is still a problem when relying on last recorded
block number returned by SCSI commands READ CAPACITY and READ TRACK
INFORMATION - that is, between block 0 and block N there may be
unwritten blocks which are located outside any track.
That said, the Partition driver was unable to find AVDP at block N on
certain medias that do not either return or report their last recorded
block number correctly.
Apparently there is no official or correct way to find the correct block
number, however tools like the Philips UDF Conformance Tool (udf_test)
apply a correction by searching for an AVDP or VAT in blocks N through
N-456 -- this can be observed by looking at the log reported by udf_test
on those CD/DVD medias. So, if the AVDP or VAT is found, then it sets
the last recorded block number to where AVDP or VAT was located.
With the below setence in UDF 2.60, 6.13.2.2 Background Physical
Formatting:
"... the second AVDP must be recorded after the Background physical
Formatting has been finished..."
Implies that the last recorded block is the one where second AVDP was
recorded.
This patch implements a similar way to correct the last recorded block
number by searching for last AVDP in blocks N-1 through N-512 on those
certain medias, as well as ensure a minimum number of 2 AVDPs found as
specified by ECMA 167 and UDF 2.60 specifications.
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Hao Wu <hao.a.wu@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=766
Update logic to not return an error from UsbBootRequestSense()
if a Request Sense command responds with no sense information.
It is legal for a USB mass storage device to respond to a
Request Sense command with a SenseKey of
USB_BOOT_SENSE_NO_SENSE and an Additional Sense
Code of USB_BOOT_ASC_NO_ADDITIONAL_SENSE_INFORMATION.
This is described in Section 3.3 of the Universal Serial
Bus Mass Storage Specification For Bootability:
http://www.usb.org/developers/docs/devclass_docs/usb_msc_boot_1.0.pdf
The previous logic returned an error of EFI_NO_RESPONSE
and this caused USB mass storage devices such as a USB
floppy drive to not be detected.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
V2:
Fix MSFT C4255 warning
V1:
Enable MSFT C4255 warning.
From MSDN:
Compiler Warning (level 4) C4255
function' : no function prototype given: converting '()' to '(void)'
The compiler did not find an explicit list of arguments to a function.
This warning is for the C compiler only.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song <binx.song@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=765
The UEFI Specification Boot Services chapter, StartImage() service,
EFF 1.10 Extension requires extra calls to ConnectController()
if a UEFI Driver produces handles. The DXE Core is performing these
extra calls to ConnectController() without evaluating the ImageType.
A filter is added to not make extra calls to ConnectController()
if the ImageType is EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION.
Without this filter, extra calls to ConnectController() may be
performed by UEFI Applications or a UEFI Shell Applications that
also call ConnectController().
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=761
When a TerminalType is set to PCANSI, characters in the range 0x00
to 0x1F are control characters. The mapping table for PCANSI maps
TRIANGLE glyphs, ARROW_UP glyph, and ARROW_DOWN glyph into this
control character range and that causes no characters to be
displayed by PCANSI compatible terminal emulators.
The mappings are updated so these glyphs are mapped to ANSI
characters in the range 0x20 to 0x7E.
GEOMETRICSHAPE_UP_TRIANGLE '^'
GEOMETRICSHAPE_RIGHT_TRIANGLE '>'
GEOMETRICSHAPE_DOWN_TRIANGLE 'v'
GEOMETRICSHAPE_LEFT_TRIANGLE '<'
ARROW_UP '^'
ARROW_DOWN 'v'
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
V2 update: Directly use NetIp4IsUnicast() to check station address in IP driver.
This patch is to follow RFC3021 which allows to use 31-bit mask
in point-to-point link.
If a 31-bit subnet mask is assigned to a point-to-point link, it
leaves the <Host-number> with only 1 bit. Consequently, only two
possible addresses may result:
{<Network-number>, 0} and {<Network-number>, -1}
These addresses have historically been associated with network and
broadcast addresses (see Section 2.2). In a point-to-point link with
a 31-bit subnet mask, the two addresses above MUST be interpreted as
host addresses.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
https://lists.01.org/pipermail/edk2-devel/2017-October/016479.html
reported "Xen Console input very slow in recent UEFI" that appears
after 4cf3f37c87 "MdeModulePkg
SerialDxe: Process timeout consistently in SerialRead".
Julien did more debugging and find out the following is happening in
TerminalConInTimerHandler (MdeModulePkg/Universal/Console/TerminalDxe)
when a character is received:
1) GetControl will return EFI_SERIAL_INPUT_BUFFER_EMPTY unset
=> Entering in the loop to fetch character from the serial
2) GetOneKeyFromSerial()
=> Return directly with the character read
3) Looping as the fifo is not full and no error
4) GetOneKeyFromSerial() -> SerialRead()
=> No more character so SerialPortPoll() will return FALSE and loop
until timeout
=> Return EFI_TIMEOUT
5) Exiting the loop from TerminalConInTimerHandler
6) Characters are printed
After some investigation, I found it is related to the Timeout value.
The Timeout is 1000000 (1s) by default to follow UEFI spec.
And the Terminal driver will recalculate and set the Timeout value
based on the properties of UART in TerminalDriverBindingStart()/
TerminalConInTimerHandler().
SerialInTimeOut = 0;
if (Mode->BaudRate != 0) {
//
// According to BAUD rate to calculate the timeout value.
//
SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) *
2 * 1000000 / (UINTN) Mode->BaudRate;
}
For example, based on the PCD values of PcdUartDefaultBaudRate,
PcdUartDefaultDataBits and PcdUartDefaultStopBits, SerialInTimeOut =
(1 + 8 + 1) * 2 * 1000000 / (UINTN) 115200 = 173 (us).
When SerialDxe is used,
TerminalDriverBindingStart()/TerminalConInTimerHandler() ->
SerialIo->SetAttributes() ->
SerialSetAttributes() ->
SerialPortSetAttributes()
Some implementations of SerialPortSetAttributes() could handle the
input parameters and return RETURN_SUCCESS, for example
BaseSerialPortLib16550, then Timeout value will be changed to 173 (us),
no "slow down" will be observed.
But some implementations of SerialPortSetAttributes() just return
RETURN_UNSUPPORTED, for example XenConsoleSerialPortLib, then Timeout
value will be not changed and kept 1000000 (1s), "slow down" will be
observed.
SerialPortLib instance can be enhanced to
1. Handle the input parameters and return status accordingly instead of
just returning RETURN_UNSUPPORTED in SerialPortSetAttributes().
2. Just return RETURN_SUCCESS instead of RETURN_UNSUPPORTED in
SerialPortSetAttributes() if the instance does not care the input
parameters at all.
And SerialDxe can also be enhanced like this patch to be more robust
to handle Timeout change.
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Compare against the original parameters
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes of
memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger
than size of "Buffer", heap memory overflow occurs during copy.
One solution is to allocate pool first then copy the necessary bytes to new
memory. Another is using ReallocatePool instead if old buffer will be freed
on spot.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Bi Dandan <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Bi Dandan <dandan.bi@intel.com>
For PciIoPciRead interface, memory prior to Buffer would be written
with zeros if Offset was larger than sizeof (Dev->ConfigSpace), which
would cause serious system exception.
So we add a pre-check branch to avoid memory override.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The patch ensures all DMA transactions are blocked after
ExitBootService.
If a platform enables IOMMU before and needs disable IOMMU after
ExitBootService, the IOMMU should be disabled after PCI bus driver
disables BME.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Turner <michael.turner@microsoft.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jeff Fan <vanjeff_919@hotmail.com>
V3:
(1) Reset QuestionStoredInBitField to FALSE at end opcode(EFI_IFR_END_OP)
(2) Fix typo and format issues(line alignment for debug print message
and value assignment...)
V2:
(1)Remove the VarOffsetBitLevel/StorageWidthBitLevel to reduce the final
VarCheckBinSize and update the implementation accordingly.
(2)Update the VAR_CHECK_HII_REVISION
(3)Refine the Debug message and function comments,like update oneof",
"checkbox", "numeric" to "OneOf", "CheckBox", "Numeric".
VarCheckHiiLib check the value set to storage based on the possible value
listed in the vfr file. Since we have enhanced vfr to support Question
value stored in bit field, so now enhance VarCheckHiiLib to support bit
field check.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In patch 2, we will introduce DEBUG_INFO in VarCheckHiiLib,in order to keep
consistence, replace all EFI_D_INFO with DEBUG_INFO firstly in this pacth.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Currently, we complete a synchronous operation without unmapping the
DMA mappings, and free the pages using FreePages () rather than calling
EFI_PCI_IO_PROTOCOL::FreeBuffer. This is simply incorrect, but it also
breaks non-coherent DMA as well as DMA protection and/or memory encryption
so let's do it correctly and call SdMmcFreeTrb() instead.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Mark EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS as deprecated.
1. Make SetVariable/QueryVariableInfo return EFI_UNSUPPORTED with this
attribute
2. No change to GetVariable/GetNextVariableName
Also update several function descriptors accordingly
Cc: Long Qin <qin.long@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Long Qin <qin.long@intel.com>
It's a regression of below commit:
SHA-1: 8be37a5cee
* MdeModulePkg/SecurityStubDxe: Defer 3rd party image before EndOfDxe
When PciBus driver fails to load the Option ROM, it doesn't produce
BusOverride protocol. It was a correct behavior before the above
commit. But due to the above commit, BusOverride protocol never is
produced by PciBus driver.
The patch fixes this issue using the following solution:
1. PciBus records the image device path when LoadImage fails.
2. Override.GetDriver() tries to look for the image handle using
the stored image device path.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The patch shouldn't impact functionality.
Original code records the ImageHandle of Option ROM by creating a
new entry. It's not necessary.
The patch updates the ImageHandle in the old entry.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The patch doesn't impact real functionality.
It only renames EFI_PCI_ROM_IMAGE_MAPPING to PCI_ROM_IMAGE,
and changes prototype of PciRomAddImageMapping so that
no explicit type cast is needed when calling this function.
It also removes unused field RomBase from PCI_IO_DEVICE structure.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Clearing I/O port decoding in the PCI command register at
ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx)
machine type. (AHCI boot on "q35" is unaffected.) Windows seems repeatedly
stuck, apparently waiting for a timeout of sorts.
This is arguably a Windows bug; a native OS driver should not expect the
firmware to leave the PCI command register in any particular state.
Strictly speaking, we only need to disable BM-DMA at ExitBootServices(),
in order to abort pending transfers to/from RAM, which is soon to be owned
by the OS. BM-DMA is also the only bit that's explicitly named by the UEFI
Driver Writers' Guide, for clearing at ExitBootServices().
I've verified that clearing only BM-DMA fixes the issue (boot time) on
i440fx, and does not regress q35/AHCI.
Cc: Aleksei Kovura <alex3kov@zoho.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dann Frazier <dannf@ubuntu.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Aleksei Kovura <alex3kov@zoho.com>
Reported-by: Dann Frazier <dannf@ubuntu.com>
Reported-by: https://launchpad.net/~cjkrupp
Bisected-by: Dann Frazier <dannf@ubuntu.com>
Bisected-by: https://launchpad.net/~cjkrupp
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Star Zeng <star.zeng@intel.com>
Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
Fixes: 6fb8ddd36b
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Tested-by: Aleksei Kovura <alex3kov@zoho.com>
According the UEFI spec 2.7 A:
In section 28.3.2 for the IpConfigData.UseDefaultAddress, "While set to
TRUE, Configure() will trigger the EFI_IP4_CONFIG2_PROTOCOL to retrieve
the default IPv4 address if it is not available yet."
In section 28.5 for the Ip4Config2PolicyDhcp, "...All of these configurations
are retrieved from DHCP server or other auto-configuration mechanism."
This patch is to align with the above description. When the default IPv4
address is not available and IpConfigData.UseDefaultAddress is set to TRUE,
Ip4Config2 protocol will be called to retrieve the default address by setting
the policy to Ip4Config2PolicyDhcp.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
VariableRuntimeDxe deletes and locks the MorLock variable in
MorLockInit(), with the argument that any protection provided by MorLock
can be circumvented if MorLock can be overwritten by unprivileged code
(i.e., outside of SMM).
Extend the argument and the logic to the MOR variable, which is supposed
to be protected by MorLock. Pass Attributes=0 when deleting MorLock and
MOR both.
This change was suggested by Star; it is inspired by earlier VariableSmm
commit fda8f631ed ("MdeModulePkg/Variable/RuntimeDxe: delete and lock
OS-created MOR variable", 2017-10-03).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Make the comments align with the function.
And add some missing function comments.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
The bug was caused by 728d74973c
"MdeModulePkg/PciBus: Count multiple hotplug resource paddings".
The patch firstly updated the Bridge->Alignment to the maximum
alignment of all devices under the bridge, then aligned the
Bridge->Length to Bridge->Alignment.
It caused too much resources were claimed.
The new patch firstly aligns Bridge->Length to Bridge->Alignment,
then updates the Bridge->Alignment to the maximum alignment of all
devices under the bridge.
Because the step to update the Bridge->Alignment is to make sure
the resource allocated to the bus under the Bridge meets all
devices alignment. But the Bridge->Length doesn't have to align
to the maximum alignment.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Existing code forgot to set Descriptor->SpecificFlag to 0 when
the resource type is non-prefetchable MMIO.
The patch adds the missing assignment.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This is the regression issue. After apply CalculateCrc32(), the parameter
check is missing.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Wu Hao A <hao.a.wu@intel.com>
Install EdkiiSmmEndOfS3ResumeProtocol when S3 resume finished.
S3ResumePei will send S3 resume finished event to SmmCore through
communication buffer.
V2 change:
None.
V3 change:
1. Uninstall the protocol right after install it to avoid run out of memory.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add gEdkiiSmmEndOfS3ResumeProtocolGuid which used by SmmCore to
notify smm drives that S3 resume has finished.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Current implementation skips to check whether the last four
characters are digits when the OptionNumber is NULL.
Even worse, it may incorrectly return FALSE when OptionNumber is
NULL.
The patch fixes it to always check the variable name even
OptionNumber is NULL.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BmCharToUint() could be called using external data and it
already contains logic to return -1 when data is invalid,
so removing unnecessary assertion to avoid system hang.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
One of issue caused by enabling NULL pointer detection is that some PCI
device OptionROM, binary drivers and binary OS boot loaders may have NULL
pointer access bugs, which will prevent BIOS from booting and is almost
impossible to fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used
as a workaround to indicate BIOS to disable NULL pointer detection right
after event gEfiEndOfDxeEventGroupGuid, and then let boot continue.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
NULL pointer detection is done by making use of paging mechanism of CPU.
During page table setup, if enabled, the first 4-K page (0-4095) will be
marked as NOT PRESENT. Any code which unintentionally access memory between
0-4095 will trigger a Page Fault exception which warns users that there's
potential illegal code in BIOS.
This also means that legacy code which has to access memory between 0-4095
should be cautious to temporarily disable this feature before the access
and re-enable it afterwards; or disalbe this feature at all.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
PCD PcdNullPointerDetectionPropertyMask is a bitmask used to control the
NULL address detection functionality in code for different phases.
If enabled, accessing NULL address in UEFI or SMM code can be caught
as a page fault exception.
BIT0 - Enable NULL pointer detection for UEFI.
BIT1 - Enable NULL pointer detection for SMM.
BIT2..6 - Reserved for future uses.
BIT7 - Disable NULL pointer detection just after EndOfDxe. This is a
workaround for those unsolvable NULL access issues in
OptionROM, boot loader, etc. It can also help to avoid
unnecessary exception caused by legacy memory (0-4095) access
after EndOfDxe, such as Windows 7 boot on Qemu.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update PeiCore to build FV3 HOB with the
authentication status and DxeCore to get the authentication
status from FV3 HOB when producing FVB Protocol.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
According to the TCG Platform Reset Attack Mitigation Specification (May
15, 2008):
> 5 Interface for UEFI
> 5.1 UEFI Variable
> 5.1.1 The MemoryOverwriteRequestControl
>
> Start of informative comment:
>
> [...] The OS loader should not create the variable. Rather, the firmware
> is required to create it and must support the semantics described here.
>
> End of informative comment.
However, some OS kernels create the MOR variable even if the platform
firmware does not support it (see one Bugzilla reference below). This OS
issue breaks the logic added in the last patch.
Strengthen the MOR check by searching for the TCG or TCG2 protocols, as
edk2's implementation of MOR depends on (one of) those protocols.
The protocols are defined under MdePkg, thus there's no inter-package
dependency issue. In addition, calling UEFI services in
MorLockInitAtEndOfDxe() is safe, due to the following order of events /
actions:
- platform BDS signals the EndOfDxe event group,
- the SMM core installs the SmmEndOfDxe protocol,
- MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services,
- some time later, platform BDS installs the DxeSmmReadyToLock protocol,
- SMM / SMRAM is locked down and UEFI services become unavailable to SMM
drivers.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The "MemoryOverwriteRequestControl" (a.k.a. MOR) variable comes from the
"TCG Platform Reset Attack Mitigation Specification":
https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf
The "MemoryOverwriteRequestControlLock" variable (a.k.a. MORL) is a
Microsoft extension, called "Secure MOR implementation":
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-requirements
Currently the VariableSmm driver creates MORL without regard to MOR. This
can lead to a situation where a platform does not support MOR from the
prerequisite spec (because it does not include the
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf" driver), but appears
to support MORL from the dependent Microsoft spec.
"winload.efi" notices this inconsistency, and disables the Device Guard
Virtualization Based Security in Windows Server 2016 and Windows 10 64-bit
Enterprise.
If the platform includes
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf", then MOR will exist
by the time EndOfDxe is reached, and VariableSmm can safely create MORL.
Otherwise, do not create MORL (delete it if it exists), and also prevent
other modules from creating it.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=727
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1496170
Reported-by: Ladi Prosek <lprosek@redhat.com>
Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The SetMorLockVariable() function sets "mMorLockPassThru" to TRUE
temporarily, so that it can set the MOR Control Lock variable to
well-formed values without permission checks.
In the next patch, we'll need the same override for deleting the MOR
Control Lock variable; hence obey "mMorLockPassThru" in the deletion
branch of SetVariableCheckHandlerMorLock() as well.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
Introduce the MorLockInitAtEndOfDxe() hook, in order to allow
MorLockInit() to delay / queue operations until EndOfDxe. (Or, if the
platform never signals EndOfDxe, until ReadyToBoot.)
Call MorLockInitAtEndOfDxe() whenever we set "mEndOfDxe" to TRUE:
- in VariableRuntimeDxe:
- in the OnReadyToBoot() function,
- in the OnEndOfDxe() function;
- in VariableSmm:
- on the SMM_VARIABLE_FUNCTION_READY_TO_BOOT SMI request,
- in the SmmEndOfDxeCallback() function.
For now, implement MorLockInitAtEndOfDxe() as a no-op in both
VariableRuntimeDxe and VariableSmm.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The MorLockInit() and SetVariableCheckHandlerMor() functions have separate
implementations for VariableRuntimeDxe (= unprivileged, unified
DXE_RUNTIME driver) and VariableSmm (= privileged, DXE_SMM back-end of the
split variable driver).
Move their declarations from "Variable.c" to "PrivilegePolymorphic.h", so
that the compiler enforce that the declarations and the definitions match.
(All C source files with the call sites and the function definitions
already include "PrivilegePolymorphic.h" via "Variable.h".)
At the same time:
- replace two typos in the MorLockInit() description:
- replace "EFI_SUCEESS" with "EFI_SUCCESS",
- replace "MOR Lock Control" with "MOR Control Lock";
- in the SetVariableCheckHandlerMor() description:
- replace @param with @param[in],
- correct the description of the Attributes parameter (suggested by Star
Zeng <star.zeng@intel.com>),
- rewrap the comment to 80 columns.
This change cleans up commit 2f6aa774fe ("MdeModulePkg: Add MorLock to
variable driver.", 2016-01-19).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
If the platform supports SMM, a gRT->SetVariable() call at boot time
results in the following call tree to SecureBootHook():
RuntimeServiceSetVariable() [VariableSmmRuntimeDxe.c, unprivileged]
SmmVariableHandler() [VariableSmm.c, PRIVILEGED]
VariableServiceSetVariable() [Variable.c, PRIVILEGED]
SecureBootHook() [VariableSmm.c, PRIVILEGED]
//
// do nothing
//
SecureBootHook() [Measurement.c, unprivileged]
//
// measure variable if it
// is related to SB policy
//
And if the platform does not support SMM:
VariableServiceSetVariable() [Variable.c, unprivileged]
SecureBootHook() [Measurement.c, unprivileged]
//
// measure variable if it
// is related to SB policy
//
In other words, the measurement always happens outside of SMM.
Because there are two implementations of the SecureBootHook() API, one
that is called from SMM and does nothing, and another that is called
outside of SMM and measures variables, the function declaration should be
in a header file. This way the compiler can enforce that the function
declaration and all function definitions match.
"Variable.h" is used for "including common header files, defining internal
structures and functions used by Variable modules". Technically, we could
declare SecureBootHook() in "Variable.h". However, "Measurement.c" and
"VariableSmmRuntimeDxe.c" themselves do not include "Variable.h", and that
is likely intentional -- "Variable.h" exposes so much of the privileged
variable implementation that it is likely excluded from these C source
files on purpose.
Therefore introduce a new header file called "PrivilegePolymorphic.h".
"Variable.h" includes this header (so that all C source files that have
been allowed to see the variable internals learn about the new
SecureBootHook() declaration immediately). In "Measurement.c" and
"VariableSmmRuntimeDxe.c", include *only* the new header.
This change cleans up commit fa0737a839 ("MdeModulePkg Variable: Merge
from Auth Variable driver in SecurityPkg", 2015-07-01).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Ladi Prosek <lprosek@redhat.com>
EFI_BOOT_SCRIPT_WRITE() interface is a var-arg interface.
Spec defines the order of parameters for
EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE as below:
typedef
EFI_STATUS
(EFIAPI *EFI_BOOT_SCRIPT_WRITE) (
IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
IN UINT16 OpCode,
IN EFI_BOOT_SCRIPT_WIDTH Width,
IN UINT16 Segment,
IN UINT64 Address,
IN UINTN Count,
IN VOID *Buffer
);
But implementation assumes Segment is in the very end, after Buffer.
Similar spec/implementation gaps are also found for
EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE.
The patch fixes the implementation to extract the arguments in
correct order.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Commit 8932679df5 adds an ASSERT for
checking NULL pointer dereference.
The ASSERT added here is for addressing a false positive NULL pointer
dereference issue raised from static analysis.
This commit adds comments to clarify the reason for using ASSERT as the
check.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=720
The current implementation assumes there is only one hotplug resource
padding for each resource type. It's not true considering
DegradeResource(): MEM64 resource could be degraded to MEM32
resource.
The patch treat the resource paddings using the same logic as
treating typical/actual resources and the total resource of a bridge
is set to the MAX of typical/actual resources and resource paddings.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The debug messages can help developer to know the pre-memory
allocation usage.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=699
Within function AhciModeInitialization(), left shift operations of 'BIT0'
in the following statements:
"if ((PortImplementBitMap & (BIT0 << Port)) != 0) {"
will incur possible out of range left shift when Port is 31, since
"1 << 31" is possible to exceed the range of type 'int' (signed).
According to the C11 spec, Section 6.5.7:
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 * 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 * 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
This commit explicitly cast 'BIT0' with UINT32 to resolve this issue.
Cc: Steven Shi <steven.shi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=698
Within function NetRandomInitSeed(), left shift a negative value is used
in:
"~Time.Hour << 24"
which involves undefined behavior.
Since Time.Hour is of type UINT8 (range from 0 to 23), hence ~Time.Hour
will be a negative value (of type int, signed).
According to the C11 spec, Section 6.5.7:
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 * 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 * 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
This commit will remove the '~' operator before 'Time.Hour', since it
seems like an implementation choice for generating the seed.
Cc: Steven Shi <steven.shi@intel.com>
Cc: Qin Long <qin.long@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695
Within function CoreRestoreTpl(), left shift a negative value -2 is used
in:
"while (((-2 << NewTpl) & gEventPending) != 0) {"
which involves undefined behavior.
According to the C11 spec, Section 6.5.7:
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 * 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 * 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
This commit refines the code logic to avoid left shifting the negative
value.
Cc: Steven Shi <steven.shi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=702
Within function InternalPrintLibSPrintMarker(), possible left shift of a
negative value is found in:
"(*(ArgumentString + 1) << 8)"
which involves undefined behavior.
Since '*(ArgumentString + 1)' is of type CONST CHAR8 (signed), it will be
promoted to type int (signed) during the left shift operation. If
'*(ArgumentString + 1)' is a negative value, the behavior will be
undefined.
According to the C11 spec, Section 6.5.7:
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 * 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 * 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
This commit explicitly cast '*(ArgumentString + 1)' with UINT8 to resolve
this issue.
Cc: Steven Shi <steven.shi@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Current implementation deletes the "BootNext" before calling
any PlatformBootManagerLib APIs, but if system resets in
PlatformBootManagerLib APIs, "BootNext" is not consumed but lost.
The patch defers the deletion of "BootNext" to before booting it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
In NetbufTrim() function, the NetBuf TotalSize should be checked with 0 before
making the trim operation, otherwise the function will fall into infinite loop.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
The patch dynamically enables Bus Master on P2P bridges only
when requested by a device driver through PciIo.Attribute() to enable
the Bus Master.
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Within function GetAllocationDescriptorLsn():
The call to GetPdFromLongAd() may return NULL and it will be later
dereferenced in GetShortAdLsn().
This commit adds ASSERT to resolve the potential NULL pointer
dereference.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Follow PI 1.6 spec to support FFS_ATTRIB_DATA_ALIGNMENT_2 for
FFS alignment extended to support maximum 16MB.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Do not reserve entire block device size for an UDF file system -
instead, reserve the appropriate space (UDF logical volume space) for
it.
Additionally, only create a logical partition for UDF logical volumes
that are currently supported by EDK2 UDF file system implementation. For
instance, an UDF volume with a single LVD and a single Physical (Type 1)
Partition will be supported.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reported-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Tested-by: Hao Wu <hao.a.wu@intel.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Build-tested-by: Star Zeng <star.zeng@intel.com>
Build-tested-by: Paulo Alcantara <paulo@hp.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Add NULL pointer check before using a pointer to avoid possible
NULL pointer dereference.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Change since v4: Revise the patch based on V4 sent by Amit Kumar
1) Only return the corresponding protocol interface in *Interface
if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
2) Interface is returned unmodified for all error conditions except
EFI_UNSUPPORTED and EFI_ALREADY_STARTED, NULL will be returned in
*Interface when EFI_UNSUPPORTED and Attributes is not
EFI_OPEN_PROTOCOL_TEST_PROTOCOL, the protocol interface will be
returned in *Interface when EFI_ALREADY_STARTED.
Change since v3:
1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL
and Inteface = NULL case. [Reported by:star.zeng at intel.com]
Change Since v2:
1) Modified to use EFI_ERROR to get status code
Change since v1:
1) Fixed typo protocal to protocol
2) Fixed coding style
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Amit Kumar <amit.ak@samsung.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Gabriel Somlo <gsomlo@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Amit Kumar <amit.ak@samsung.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545
For oneof/numeric/CheckBox(storage can be Bit VarStore)
If the question value can be updated and shown correctly
in UI page, we need do enhancements in following cases:
1. Parse the Ifr data to get the bit VarStore info correctly.
2. Set/get value to/from bit VarStore correctly.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545
For oneof/numeric/checkbox, their storage may be bit field.
When generating <ConfigAltResp> string to get default value
for these questions, we need to parse the Ifr data to get
the bit Varstore info,and then generating the correct
<ConfigAltResp> string.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545
In UefiHiiLib, there are codes to validate the current setting of
questions, now update the logic to handle question with bit storage.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept page
related attributes. That means users cannot use it to change page attributes,
and have to turn to CPU arch protocol to do it, which is not be allowed by PI
spec.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Similar to the naming style for variables, it's better for the name of
members in a enum type to avoid using only upper-case letters.
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The local GUID variable 'UdfDevPathGuid', it has been initialized during
its declaration.
For better coding style, this commit uses a global variable instead.
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In ResolveSymlink(), replace the following variable:
CHAR16 *C;
with:
CHAR16 *Char;
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Case 1 - Within DuplicateFid() & DuplicateFe():
The call to AllocateCopyPool() may return NULL.
Add ASSERTs as checks.
Case 2 - Within UdfRead():
Add ASSERT to ensure 'NewFileEntryData' returned from FindFileEntry()
will not be NULL pointer.
Case 3 - Within GetAllocationDescriptorLsn():
The return value of 'GetPdFromLongAd (Volume, ParentIcb)' may be NULL,
and it will be passed into function GetShortAdLsn() which will
dereference it.
Add ASSERT in GetShortAdLsn() as check.
Case 4 - Within ReadFile():
Add ASSERT to ensure 'Data' returned from GetAedAdsData() will not be NULL
pointer.
Case 5 - Within InternalFindFile():
If both 'Parent->FileIdentifierDesc' and 'Icb' are NULL, then possible
NULL pointer dereference will happen in ReadDirectoryEntry().
Add additional check to resolve.
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Issue : When try to change serial attributes using sermode
command, the default values are set with the execute flow
as below.
The sermode command calls SerialSetAttributes, which sets H/W
attributes of Serial device. After that the SerialIo protocol is
reinstalled, which causes MdeModulePkg/Universal/Console/TerminalDxe
and MdeModulePkg/Universal/Console/ConPlatformDxe drivers' bindings
to stop and then start. This in turn calls SerialReset, which undoes
changes of SerialSetAttributes.
Cause : The SerialReset command resets the attributes' values
to default.
Fix : Serial Reset command should set the attributes which have
been changed by user after calling SerialSetAttributes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The generic driver has no way to know whether an OEM type should
be filtered or not.
This patch is to update the code to skip measurement for OEM type
and platform code can measure it by self if required.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Update XHCI driver to consume IOMMU_PPI to allocate DMA buffer.
If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.
This is a compatible change.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This IOMMU_PPI is to provide IOMMU abstraction in PEI.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=704
For root directory, the FID (File Identifier Descriptor) pointer is
accessible through PRIVATE_UDF_FILE_DATA.Root, whereas non-root
directory and regular files, their FIDs are accessible through
PRIVATE_UDF_FILE_DATA.File.
In UdfSetPosition(), the FID was retrieved through
PRIVATE_UDF_FILE_DATA.File, hence when calling it with a root directory,
PRIVATE_UDF_FILE_DATA.File.FileIdentifierDescriptor would be NULL and
then dereferenced.
This patch fixes the NULL pointer dereference by calling _FILE() to
transparently return the correct UDF_FILE_INFO * which points to a valid
FID descriptor of a specific file.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Steven Shi <steven.shi@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
VS2010/VS2012 build failure with below info:
warning C4701:
potentially uninitialized local variable 'DataOffset' used
potentially uninitialized local variable 'FilePosition' used
potentially uninitialized local variable 'FinishedSeeking' used
potentially uninitialized local variable 'Data' used
warning C4703:
potentially uninitialized local pointer variable 'Data' used
In fact, DataOffset, FilePosition and FinishedSeeking are initialized
and then used if (ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ).
DoFreeAed will be set to TRUE when Data is allocated and returned from
GetAedAdsData(), and Data will be freed if (DoFreeAed) when exiting.
Use same method at 5afa5b8159 to fix
the build failure.
There is related discussion at
https://lists.01.org/pipermail/edk2-devel/2017-September/014641.html
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
When building the driver for DEBUG/RELEASE, GCC48/GCC49 warn about
ReadFile() possibly using "BytesLeft" without initializing it first.
This is not the case. The reads of "BytesLeft" are only reachable if
(ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ). But, in that case, we
also set "BytesLeft" to "ReadFileInfo->FileDataSize", near the top of the
function.
Assign "BytesLeft" zero at the top, and add a comment that conforms to the
pending Coding Style Spec feature request at
<https://bugzilla.tianocore.org/show_bug.cgi?id=607>.
This issue was reported by Ard's and Gerd's CI systems independently.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
The ECMA-167 standard (3rd Edition, June 1997) reserves values 4 through 7
in the ICB.Flags[2:0] bit-field for future standardization; see "14.6 ICB
Tag" / "14.6.8 Flags (RBP 18)".
https://www.ecma-international.org/publications/standards/Ecma-167.htm
The
switch (RecordingFlags)
statement in the ReadFile() function handles all the standard values,
using the constants of the UDF_FE_RECORDING_FLAGS enum type. However, the
reserved values are not caught with a "default" case label, which both
breaks the edk2 Coding Style Spec, and leaves the Status variable
un-initialized, before we return Status under the Done label.
Set Status to EFI_UNSUPPORTED if we encounter a reserved value.
This issue was reported by Ard's and Gerd's CI systems independently
(through build failures with GCC48/GCC49, DEBUG/RELEASE targets).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
To avoid the function name conflict, update the internal function name
to be the specific one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch gets rid of a negative comparison of an UINT64 type (Offset)
as it'll never evaluate to true.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Star Zeng <star.zeng@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In the expression
(RemainderByMediaBlockSize != 0 ||
Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE)
the second expression is only evaluated if the first expression is false.
If the first expression is false, i.e.,
RemainderByMediaBlockSize == 0
then UDF_LOGICAL_SECTOR_SIZE is a whole multiple of "Media->BlockSize",
which implies
UDF_LOGICAL_SECTOR_SIZE >= Media->BlockSize.
Therefore whenever
Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE
is evaluated, it is false.
The expression
((expression) || FALSE)
is equivalent to
(expression).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In edk2, the division and shifting of 64-bit values are forbidden with
C-language operators, because the compiler may generate intrinsic calls
for them.
For example, clang-3.8 emits a call to "__umoddi3" for
UDF_LOGICAL_SECTOR_SIZE % Media->BlockSize
in PartitionInstallUdfChildHandles(), if PartitionDxe is built for IA32,
which then fails to link.
UDF_LOGICAL_SECTOR_SIZE has type UINT64, while
EFI_BLOCK_IO_MEDIA.BlockSize has type UINT32(). Replace the % operator
with a DivU64x32Remainder() call.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In edk2, initialization of local variables is forbidden, both for
stylistic reasons and because such initialization may generate calls to
compiler intrinsics.
For the following initialization in UdfRead():
CHAR16 FileName[UDF_FILENAME_LENGTH] = { 0 };
clang-3.8 generates a memset() call, when building UdfDxe for IA32, which
then fails to link.
Replace the initialization with ZeroMem().
Do the same to "FilePath" in UdfOpen().
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard reports that clang-3.8 correctly flags the following issue in the
ReadFile() function:
If "RecordingFlags" is INLINE_DATA, then there are three paths through the
code where we mean to return success, but forget to set Status
accordingly:
(1) when "ReadFileInfo->Flags" is READ_FILE_GET_FILESIZE, or
(2) when "ReadFileInfo->Flags" is READ_FILE_ALLOCATE_AND_READ and
AllocatePool() succeeds, or
(3) when "ReadFileInfo->Flags" is READ_FILE_SEEK_AND_READ.
Set "Status" to EFI_SUCCESS when we are done processing the INLINE_DATA
request, i.e., when we reach the corresponding "break" statament under the
INLINE_DATA case label.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In the ReadFile() function, if "RecordingFlags" is INLINE_DATA, then we
cover the following values of "ReadFileInfo->Flags":
- READ_FILE_GET_FILESIZE
- READ_FILE_ALLOCATE_AND_READ
- READ_FILE_SEEK_AND_READ
We don't do anything (just proceed to the end of the function) if
"ReadFileInfo->Flags" is anything else.
In reality the above three values cover the domain of the
UDF_READ_FILE_FLAGS enum type fully, and "ReadFileInfo->Flags" is only
ever set internally to UdfDxe. Therefore any other flag value would be a
bug in UdfDxe.
ASSERT() specifically that "ReadFileInfo->Flags" has been set correctly,
so that the reader is not left wondering what happens if none of the enum
constants match.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
V3: Remove one unnecessay type cast in patch 1.
Codes:
if (FilePosition + ExtentLength > ReadFileInfo->FilePosition) {
Offset = ReadFileInfo->FilePosition - FilePosition;
if (Offset < 0) {
Offset = -(Offset)
}
...
}
Offset is UINT64 can not < 0, so the code logic may have some issue.
and Offset = -(Offset) may build failure in some circumstance.
Previously type cast Offset to INT64 to fix build break. Now remove
the type cast. Then can to check the code logic later.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
"UsbSelectConfig: failed to connect driver %r, ignored" is an error
message, but it states at once that the error condition will not affect
the control flow. Degrade the report to DEBUG_WARN.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=653
Correct description of Timeout param in XhciReg.h to be matched with
XhciReg.c.
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
This patch introduces UDF file system support in EDK2. All block devices
that support BlockIo and DiskIo protocols and contain a valid UDF file
system - as specified by OSTA Universal Disk Format (revisions 1.02
through 2.60) - will be installed EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to
provide access to underlying file system.
File system operations on regular, directory and symlink files are
supported.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Scan for UDF file systems on all block devices, as specified by OSTA
Universal Disk Format Specification 2.60, and install a Vendor-Defined
Media Device Path for each file system found.
The Vendor-Defined Media Device Path for the UDF file system is then
checked by UdfDxe to decide whether or not start the driver.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The AtaAtapiPassThru driver maps three system memory regions for Bus
Master Common Buffer operation on the following call path, if the
controller has PCI_CLASS_MASS_STORAGE_SATADPA class code:
AtaAtapiPassThruStart()
EnumerateAttachedDevice()
AhciModeInitialization()
AhciCreateTransferDescriptor()
The device is disabled (including Bus Master DMA) when the controller is
unbound, in AtaAtapiPassThruStop(). Then the regions are unmapped.
The former step should also be done when we exit the boot services, and
the OS gains ownership of system memory.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fu Siyuan
Paulo Alcantara
Michael D Kinney
Song, BinX
Star Zeng
Jian J Wang
Heyi Guo
Ruiyu Ni
Dandan Bi
Ard Biesheuvel
Liming Gao
Zhang, Chao B
Laszlo Ersek
Jiaxin Wu
Eric Dong
Hao Wu
Amit Kumar
Pankaj Bansal
Jiewen Yao