https://bugzilla.tianocore.org/show_bug.cgi?id=767
The USB I/O Protocol function ControlTransfer() has a DataLength
parameter that specifies the size of the Data buffer. The
UsbBusDxe module implements the USB I/O Protocol using the
services of the USB2 Host Controller Protocol. The DataLength
parameter in the USB2 Host Controller Protocol ControlTransfer()
service is an IN OUT parameter so the number of bytes actually
transferred is returned. Since the USB I/O Protocol
ControlTransfer() service can not return the number of bytes
actually transferred, the only option if the number of bytes
actually transferred is less than the number of bytes requested
is to return EFI_DEVICE_ERROR.
The change fixes an issue with a USB mass storage device that
responds with 0 bytes to the Get MAX LUN command.
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>
when build a single module with GenC/GenMake option, currently it will
direct return after create Autogen code files, then it cause MaList is
empty, which cause an incorrect error message is reported.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The build error is introduced by following check in:
2930ef9809235a4490c8
The Visual Studio older than 2015 doesn't support constant integer
in binary format (0bxxx). This patch changes them to BIT macro to
fix it. This patch also cleans up coding style about unmatched
comment for return value.
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>
Following check-in caused this issue:
2930ef9809
This issue is caused by assigning incorrect value to PoolHdr.Size
if the requested size is more than MAX_POOL_SIZE, because the SMM
core will actually allocate page memory instead of pool memory in
this situation.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Wu Hao <hao.a.wu@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: Wu Hao <hao.a.wu@intel.com>
Tested-by: Wu Hao <hao.a.wu@intel.com>
when collect source files list we should also consider build rule
family. BuildRuleFamily may be set to the different one. It will
impact BuildRule and source files in INF file.
Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=780
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In function FindFileEntry():
Instead of using the function parameter 'FileEntry', use a local
variable to store the buffer allocated for disk read operation.
For the below calling stack:
UdfOpenVolume() -> FindRootDirectory() -> FindFileEntry()
In FindFileEntry(), the call to 'DiskIo->ReadDisk()' is possible (e.g.
media change for a CD/DVD ROM device) to trigger a re-install of the
BlockIO(2) protocol which will further lead to a call of the BindingStop()
& BingdingStart() of the UdfDxe driver.
Meanwhile, for the above listed calling stack, the '**FileEntry'
parameter passed into FindFileEntry() is '&PrivFsData->Root'. 'PrivFsData'
is a driver-managed private data, it will be freed in BindingStop() and
re-allocate in BingdingStart().
In such case, if '*FileEntry' is used to store the allocated buffer, the
information will be lost if 'DiskIo->ReadDisk()' triggers a re-install of
the BlockIO(2) protocol. The subsequent call of the FreePool API:
FreePool (*FileEntry);
will cause issues.
This commit uses a local variable to store the allocated buffer.
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>
In order to create all of the children (El Torito standard and UDF) for
a CD/DVD media in an entry of the PartitionDriverBindingStart(), this
commit merges the discovery of the El Torito feature
(PartitionInstallElToritoChildHandles) into function
PartitionInstallUdfChildHandles.
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>
Remove dependencies on gArmTokenSpaceGuid.PcdSystemMemoryBase and
gArmTokenSpaceGuid.PcdSystemMemorySize, the presence of which in
a [FixedPcd] section makes this module unusable for ArmVirtQemu.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=782
Update the Request Sense check for the Request Sense Key of
USB_BOOT_SENSE_UNIT_ATTENTION. For this Sense Key, the
Additional Sense Key to EFI_STATUS mappings are:
USB_BOOT_ASC_MEDIA_CHANGE -> EFI_MEDIA_CHANGE
USB_BOOT_ASC_NOT_READY -> EFI_NOT_READY
USB_BOOT_ASC_NO_MEDIA -> EFI_NOT_READY
All others -> EFI_DEVICE_ERROR
A USB flash drive is returning Request Sense Key of
USB_BOOT_SENSE_UNIT_ATTENTION and an Additional Sense Key of
USB_BOOT_ASC_NO_MEDIA for a few seconds before returning an
Additional Sense Key of USB_BOOT_ASC_MEDIA_CHANGE.
The current logic treats this initial Request Sense info as an
error and reties the command 5 times before failing completely.
With this change the USB Flash Drive works correctly.
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>
When SEV is enabled, every debug message printed by OVMF to the
QEMU debug port traps from the guest to QEMU character by character
because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore,
when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000)
enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
library instance that is built into it, produce a huge amount of
log messages. Therefore, in SEV guests, the boot time impact is huge
(about 45 seconds _additional_ time spent writing to the debug port).
While these messages are very useful for analyzing guest behavior,
most of the time the user won't be capturing the OVMF debug log.
In fact libvirt does not provide a method for configuring log capture;
users that wish to do this (or are instructed to do this) have to resort
to <qemu:arg>.
The debug console device provides a handy detection mechanism; when read,
it returns 0xE9 (which is very much unlike the 0xFF that is returned by
an unused port). Use it to skip the possibly expensive OUT instructions
when the debug I/O port isn't plugged anywhere.
For SEC, the debug port has to be read before each full message.
However:
- if the debug port is available, then reading one byte before writing
a full message isn't tragic, especially because SEC doesn't print many
messages
- if the debug port is not available, then reading one byte instead of
writing a full message is still a win.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash. The solution is
to have two library instances, one for SEC and another
for all other firmware phases. This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove Uefi.h, which includes UefiSpec.h, and change the
return value to match the RETURN_STATUS type.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(1) In the PEI phase, the PCD database is maintained in a GUID HOB. In
OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI),
so that all other PEIMs can use dynamic PCDs. Consequently,
- the PCD GUID HOB is initially allocated from the temporary SEC/PEI
heap,
- whenever we introduce a dynamic PCD to a PEIM built into OVMF such
that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and
its temporary heap footprint) grow.
I've noticed that, if we add just one more dynamic PCD to the PEI
phase, then in the X64 build,
- we get very close to the half of the temporary heap (i.e., 8192
bytes),
- obscure PEI phase hangs or DXE core initialization failures
(ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and
FD_SIZE_4MB builds of X64 OVMF.
(2) I've found that commit
2bbd7e2fbd ("UefiCpuPkg/MtrrLib: Update algorithm to calculate
optimal settings", 2017-09-27)
introduced a large (16KB) stack allocation:
> The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
> MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation.
> ...
> +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB)
> ...
> @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings (
> ...
> + UINT8 Scratch[SCRATCH_BUFFER_SIZE];
(3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit
7cb6b0e068 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to
0x810000", 2014-01-21)
Of that, the upper 16KB half is stack (growing down), and the lower
16KB half is heap.
Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in
QemuInitializeRam(), cause the Scratch array to overflow the entire
stack (heading towards lower addresses), and corrupt the heap below
the stack. It turns out that the total stack demand is about 24KB, so
the overflow is able to corrupt the upper 8KB of the heap. If that
part of the heap is actually used (for example because we grow the PCD
GUID HOB sufficiently), mayhem ensues.
(4) Right after commit 7cb6b0e068 (see above), there would be no room
left above the 32KB temp SEC/PEI RAM. However, given more recent
commits
45d8708151 ("OvmfPkg/PlatformPei: rebase and resize the permanent
PEI memory for S3", 2016-07-13)
6b04cca4d6 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase,
PcdS3AcpiReservedMemorySize", 2016-07-12)
we can now restore the temp SEC/PEI RAM size to the original
(pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI
stack, which accommodates the ~24KB demand mentioned in (3).
(Prior patches in this series will let us monitor the stack usage in
the future.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
Ref: http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com
Ref: http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
"Main.asm" calls TransitionFromReal16To32BitFlat (and does some other
things) before it jumps to the platform's SEC entry point.
TransitionFromReal16To32BitFlat enters big real mode, and sets the DS, ES,
FS, GS, and SS registers to offset ("selector") LINEAR_SEL in the GDT
(defined in "UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm"). The
GDT entry ("segment descriptor") at LINEAR_SEL defines a segment covering
the full 32-bit address space, meant for "read/write data".
Document this fact for all the affected segment registers, as output
parameters for TransitionFromReal16To32BitFlat, saying "Selector allowing
flat access to all addresses".
For 64-bit SEC, "Main.asm" calls Transition32FlatTo64Flat in addition,
between calling TransitionFromReal16To32BitFlat and jumping to the SEC
entry point. Transition32FlatTo64Flat enters long mode. In long mode,
segmentation is largely ignored:
- all segments are considered flat (covering the whole 64-bit address
space),
- with the (possible) exception of FS and GS, whose bases can still be
changed, albeit with new methods, not through the GDT. (Through the
IA32_FS_BASE and IA32_GS_BASE Model Specific Registers, and/or the
WRFSBASE, WRGSBASE and SWAPGS instructions.)
Thus, document the segment registers with the same "Selector allowing flat
access to all addresses" language on the "Main.asm" level too, since that
is valid for both 32-bit and 64-bit modes.
(Technically, "Main.asm" does not return, but RBP/EBP, passed similarly to
the SEC entry point, is already documented as an output parameter.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Switch to the new, cleaned up PL011UartLib implementation so we will
be able to remove the old one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The PL011 code in ArmPlatformPkg is organized in a weird way: there is
a single PL011Uart.h header file under Include/Drivers containing both
register definitions and function entry points. The PL011Uart library
itself is in Drivers/ but it is actually a library.
So let's clean this up: add a new PL011UartLib library class and associated
header file containing only the library prototypes, and move the library
itself under Library/ using a new GUID, with the register definitions moved
into a local header file.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
XenHypercallLib uses the 'hvc' instruction, which is not implemented
on all ARMv7 CPUs, and so we need to explicitly specify a CPU that
has the virtualization extensions.
This override used to be set at the platform level, but this was removed
in commit 0d36a219c7
('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
reference), under the assumption that all users of the 'hvc' instruction
had already been fixed.
So fix this for GNU binutils by adding the 'virt' arch extension
directive, and for RVCT by setting the --cpu command line option to a
CPU that is virt capable.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Update the SdBlockIoPei 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: Jiewen Yao <jiewen.yao@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>
Update the EmmcBlockIoPei 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: Jiewen Yao <jiewen.yao@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>
V2 changes:
Resource cleanup logic update in UfsEndOfPei().
V1 history:
Update the UfsBlockIoPei 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: Jiewen Yao <jiewen.yao@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>
1. Call IoMmuInit() after locating gPeiUsbControllerPpiGuid.
2. Call XhcPeiFreeSched() to do cleanup in XhcEndOfPei.
Cc: Jiewen Yao <jiewen.yao@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>
V2: Halt HC at EndOfPei.
Update the EhciPei 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.
Cc: Jiewen Yao <jiewen.yao@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>
This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.
This feature is controlled by three PCDs:
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType
BIT2 and BIT3 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for SMM page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiRuntimeServicesCode
and EfiRuntimeServicesData by setting the PCD with value 0x60.
Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Heap guard makes use of paging mechanism to implement its functionality. But
there's no protocol or library available to change page attribute in SMM mode.
A new protocol gEdkiiSmmMemoryAttributeProtocolGuid is introduced to make it
happen. This protocol provide three interfaces
struct _EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL {
EDKII_SMM_GET_MEMORY_ATTRIBUTES GetMemoryAttributes;
EDKII_SMM_SET_MEMORY_ATTRIBUTES SetMemoryAttributes;
EDKII_SMM_CLEAR_MEMORY_ATTRIBUTES ClearMemoryAttributes;
};
Since heap guard feature need to update page attributes. The page table
should not set to be read-only if heap guard feature is enabled for SMM
mode. Otherwise this feature cannot work.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.
This feature is controlled by three PCDs:
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType
BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiBootServicesData
and EfiRuntimeServicesData by setting the PCD with value 0x50.
Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.
Note1: Turning on heap guard, especially pool guard, will introduce too many
memory fragments. Windows 10 has a limitation in its boot loader, which
accepts at most 512 memory descriptors passed from BIOS. This will prevent
Windows 10 from booting if heap guard is enabled. The latest Linux
distribution with grub boot loader has no such issue. Normally it's not
recommended to enable this feature in production build of BIOS.
Note2: Don't enable this feature for NT32 emulation platform which doesn't
support paging.
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: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Heap guard feature needs paging to work properly. 64-bit BIOS uses
PcdDxeIplBuildPageTables to control the page table setup. 32-bit BIOS
has to check heap guard feature to decide enabling paging or not.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Heap guard feature will frequently update page attributes. The debug message
in CpuDxe driver will slow down the boot performance noticeably. Changing the
debug level to DEBUG_VERBOSE to reduce the message output for normal debug
configuration.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
The new protocol gEdkiiSmmMemoryAttributeProtocolGuid is intended for
PiSmmCore to be able to change memory page attributes for the sake of
heap guard feature.
This protocol provides three interfaces to get/set/clear page attribute.
struct _EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL {
EDKII_SMM_GET_MEMORY_ATTRIBUTES GetMemoryAttributes;
EDKII_SMM_SET_MEMORY_ATTRIBUTES SetMemoryAttributes;
EDKII_SMM_CLEAR_MEMORY_ATTRIBUTES ClearMemoryAttributes;
};
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@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: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Add definitions and strings for following new PCDs:
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@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: Jiewen Yao <jiewen.yao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Now that the PL031 RTC driver library no longer depends on the ARM
platform specific ArmPlatformSysConfigLib, we no longer need to
implement ArmPlatform.h or have a resolution for that library.
This allows us to get rid of a rather dodgy practice of including
platform headers using compiler flags, which is a bad idea at various
levels.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The PL031 driver implements a VExpress/Juno specific hack to set the
battery backed clock in addition to the PL031. However, none of the
remaining VExpress based hardware we support in EDK2 actuall implements
this feature so we can just remove it, and get rid of the cumbersome
dependency on ArmPlatform.h.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Currently, each ARM platform built with RVCT that uses ArmHvcLib
or ArmSmcLib needs to specify a CPU target that implements both the
security and virtualization extensions, so that the assembler does
not choke on the 'hvc' and 'smc' instructions in ArmHvcLib/ArmSvcLib.
Let's move these overrides into the module .INFs so we can lift this
requirement at the platform side.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
assuming such regions always have full memory semantics. Given that
those regions cannot be mapped as ordinary memory on ARM (due to the
fact that the NOR flash requires device semantics while in write mode)
this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
since it may use unaligned accesses and/or DC ZVA instructions, both
of which are incompatible with mappings using device semantics.
Note that there is no way we can work around this by changing the
mapping type between 'memory' and 'device' when switching from read to
write mode and back, because the runtime mapping is created by the OS,
and cannot be changed at will.
So let's just switch to the unaccelerated version of BaseMemoryLib which
does not have the same problem.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Shannon Zhao <zhaoshenglong@huawei.com>
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>
This patch is to fix a bug that the HttpTcpReceiveHeader() may return incorrect
SizeofHeaders, which will include some already received message-body.
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>
Since UefiCpuPkg's CpuDxe Driver already adds Local Apic's MMIO space to
GCD, CorebootModulePkg's CbSupportDxe should not do this again. Doing this
again causes error return status from GCD service, and ASSERT (FALSE) with
debug build, so the duplicated addition is removed.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=779
For the API EfiShellOpenRootByHandle():
The return status of the call to SimpleFileSystem->OpenVolume should be
checked.
It is possible that there is a media change in the device (like CD/DVD
ROM). In such case, the volume root opened and/or the device path opened
previously (also within EfiShellOpenRootByHandle) may be invalid.
This commit adds a check for the result of OpenVolume before subsequently
calling functions like EfiShellGetMapFromDevicePath() &
ConvertEfiFileProtocolToShellHandle().
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@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=768
Update and simplify boot mode handling logic. This includes
performing minimum connects for the following boot modes:
BOOT_ASSUMING_NO_CONFIGURATION_CHANGES
BOOT_WITH_MINIMAL_CONFIGURATION
BOOT_ON_S4_RESUME
Cc: Kelly Steele <kelly.steele@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Kelly Steele <kelly.steele@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=769
Remove extra carriage return that causes formatting
issues.
Cc: Kelly Steele <kelly.steele@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Kelly Steele <kelly.steele@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>
Reviewed-by: Jaben Carsey <jaben.carsey@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>
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>
Michael D Kinney
Yonghong Zhu
Jian J Wang
Hao Wu
Ard Biesheuvel
Paolo Bonzini
Laszlo Ersek
Star Zeng
Pipat Methavanitpong
Fu Siyuan
Benjamin You
Paulo Alcantara
Song, BinX