Dear Experts,
Rcently, I find udk open source SVN cannot be accessed.
(https://svn.code.sf.net/p/edk2/code/trunk/edk2)
According to http://www.tianocore.org/edk2, it says:
Source repositories: git {github, bitbucket, sourceforge, more info}, svn
{sourceforge}
So if we want
As variable HEADER_ALIGNMENT = 4, the MonotonicCount in
AUTHENTICATED_VARIABLE_HEADER may be not UINT64 aligned,
so go to use ReadUnaligned64() to ensure read data correctly.
Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
Enhance the setupbrowserdxe to output debug message when DisplayEngineDxe is
not installed and this will be easy for user to find the reason why can not
enter Setup page.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi dandan...@intel.com
---
On 2015-07-23 23:14:17, winddy wrote:
Dear Experts,
Rcently, I find udk open source SVN cannot be accessed.
(https://svn.code.sf.net/p/edk2/code/trunk/edk2)
The reason for this is that sourceforge svn servers have been offline
for over a week now.
On 07/24/15 03:51, Zeng, Star wrote:
Ok for me.
Does it need the patch owner (I mean these patches for me) to commit
the patches by themselves? Or have one person to help do that commit
work all together?
No help is needed from the individual contributors for those patches
that Jordan
I just pulled the edk2-svn-offline code and took a look.
And I found Jordan had a commit for the attached patch which has been committed
in SVN at 18031 and I also have git-svn r18031 in local. Is it still needed in
this temporary git repo?
Thanks,
Star
-Original Message-
From:
Reviewed-by: Jeff Fan jeff@intel.com
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, July 24, 2015 7:36 AM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [PATCH] IntelFrameworkModulePkg: GenericBdsLib: set Status before use
The recent
On Fri, 2015-07-24 at 00:08 +0200, Laszlo Ersek wrote:
Any non-EFIAPI function using varargs is broken, isn't it?
Correct, with one tweak: any non-EFIAPI function accessing varargs with
the VA_* macros from Base.h is broken.
Can we *make* them break? I don't know, something like 'volatile
OpenSSL 1.1 introduces new OBJ_get0_data() and OBJ_length() accessor
functions and makes ASN1_OBJECT an opaque type.
Unlike the accessors in previous commits which *did* actually exist
already but just weren't mandatory, these don't exist in older versions
of OpenSSL. So introduce macros which do
In OpenSSL 1.1, the X509_ATTRIBUTE becomes an opaque structure and we will
no longer get away with accessing its members directly. Use the accessor
functions X509_ATTRIBUTE_get0_object0() and X509_ATTRIBUTE_get0_type()
instead.
Also be slightly more defensive about unlikely failure modes.
Hi,
Please help.
Regards,
Meenakshi
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Meenakshi Aggarwal
Sent: Friday, July 24, 2015 10:27 AM
To: Ni, Ruiyu; Tian, Feng; edk2-devel@lists.01.org
Subject: Re: [edk2] Filesystem support
Hi,
Thank
There have been a number of changes in OpenSSL HEAD, which will
eventually be released as OpenSSL 1,1, to clean up their header files
and make some structures opaque.
This set of patches adds explicit includes for headers which were
previously included indirectly, and also uses the accessor
Use the new OBJ_get0_data() accessor to compare the data, and actually
check the length of the object too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
But actually, I just threw up in my mouth a little bit. Because OpenSSL
On Jul 24, 2015, at 3:33 AM, David Woodhouse dw...@infradead.org wrote:
On Fri, 2015-07-24 at 00:08 +0200, Laszlo Ersek wrote:
Any non-EFIAPI function using varargs is broken, isn't it?
Correct, with one tweak: any non-EFIAPI function accessing varargs with
the VA_* macros from Base.h
On 2015-07-19 09:56:11, Jordan Justen wrote:
On 2015-07-19 04:08:50, Laszlo Ersek wrote:
On 07/19/15 12:01, Ard Biesheuvel wrote:
I'd suggest that we just promote the GitHub repository to primary
repository, and deprecate the public SVN right away.
I don't think this would be a
On 07/25/15 01:40, Jordan Justen wrote:
On 2015-07-19 09:56:11, Jordan Justen wrote:
On 2015-07-19 04:08:50, Laszlo Ersek wrote:
On 07/19/15 12:01, Ard Biesheuvel wrote:
I'd suggest that we just promote the GitHub repository to primary
repository, and deprecate the public SVN right away.
I
Before introducing the SMM driver interface, clean up #include directives
and [LibraryClasses] by:
- removing what's not directly used,
- adding what's used but not spelled out,
- sorting the result.
This helps with seeing each source file's dependencies and with
determining the library classes
When the user requires security by passing -D SMM_REQUIRE, and
consequently by setting PcdSmmSmramRequire, enforce flash-based variables.
Furthermore, add two ASSERT()s to catch if the wrong module were pulled
into the build.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 16
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c| 16
In preparation for introducing an SMM interface to this driver, move the
following traits to separate files, so that we can replace them in the new
SMM INF file:
- Protocol installations. The SMM driver will install protocol interfaces
in the SMM protocol database, using SMM services.
-
EFI_MP_SERVICES_PROTOCOL can be provided even when the system has only one
logical processor (the BSP); the behavior of EFI_MP_SERVICES_PROTOCOL
member functions is well defined. Some drivers (will) depend on the
presence of EFI_MP_SERVICES_PROTOCOL even if there's just a BSP, so let's
install
The logic visible in the previous patch should be done at startup as well,
not only when MTRR settings are changed. The inspiration is taken from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/
(see the EarlyMpInit() function and its call sites in
ProcessorConfig.c).
Cc: Jeff Fan
This field is simply pointed to the same AcpiNVS block in which
UefiCpuPkg/CpuDxe maintains the most recent MTRR settings.
This way PiSmmCpuDxeSmm will stash the then most recent MTRR settings from
AcpiNVS to SMRAM -- on the normal boot path, in
SmmReadyToLockEventNotify() --, and on the S3
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as physical address,
while the entry at subscript
The following modules constitute the variable driver stack:
- QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime
alternatives for providing the Firmware Volume Block(2) Protocol,
dependent on qemu pflash presence,
- FaultTolerantWriteDxe, providing the Fault Tolerant Write
The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never
used. Remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -
In this patch we incorporate code from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates the
following fields in ACPI_CPU_DATA for PiSmmCpuDxeSmm:
- ACPI_CPU_DATA.GdtrProfile
- ACPI_CPU_DATA.IdtrProfile
- ACPI_CPU_DATA.ApMachineCheckHandlerBase
-
The StartupVector member of ACPI_CPU_DATA points to low level assembly
code that starts out in real mode, and is the boot code that gets run on
each AP in response to an INIT-Start-up-Start-up IPI sequence.
Importantly, *each* one of PiSmmCpuDxeSmm and CpuMpDxe (from
This header file is another dependency of PiSmmCpuDxeSmm.
It should actually belong under Include/IndustryStandard, and not be
listed in the DEC file (since it is not a standalone library class and
it's not associated with any library instance), but let's follow the
structure of
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.c
Import the following (likely nonstandard) protocol definitions:
- SMM_CPU_SYNC_PROTOCOL
- SMM_CPU_SYNC2_PROTOCOL
- EFI_SMM_CPU_SERVICE_PROTOCOL
All of these are needed by PiSmmCpuDxeSmm.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
so that it ends with the RAM below 4GB,
- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
created for the RAM below 4GB; plus
The
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe
driver provides the following capability in its implementation of
EFI_CPU_ARCH_PROTOCOL: whenever the SetMemoryAttributes() member is used
(directly, or indirectly via gDS-SetMemorySpaceAttributes()) to change
MTRR settings, the complete
The argument in the previous patch applies, with the following
differences:
- CpuMpDxe is theoretically capable of adding register entries (MSR, CRn
changes etc) to these tables. See the following call tree in CpuMpDxe:
ProduceRegisterTable()
MaxCpuidLimitReg()
WriteRegisterTable(
We build this driver for X64 as well -- the comment isn't overly
important, but it shouldn't be misleading.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 +-
1 file
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 89
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c | 66 +++
2 files changed, 155
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.
One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/README | 39
1 file changed, 39 insertions(+)
diff --git a/OvmfPkg/README b/OvmfPkg/README
index 147e6e0..757f429 100644
--- a/OvmfPkg/README
+++
On 2015-07-24 09:37:49, Laszlo Ersek wrote:
Jordan,
On 07/24/15 06:37, Dong, Eric wrote:
Reviewed-by: Eric Dong eric.d...@intel.com
-Original Message-
From: Ni, Ruiyu
Sent: Thursday, July 23, 2015 5:15 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric
Subject:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfileInternal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfileInternal.h
The only dependency PiSmmCpuDxeSmm actually has on CpuConfigLib is some
type definitions from the library interface; that is, the header file. No
functions are called and no extern variables are used from the library
instance.
By not linking against CpuConfigLib in our PiSmmCpuDxeSmm port, we can
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the
SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the
mSmmControl2-Trigger() call in the SmmCommunicationCommunicate() function
[MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c].
Contributed-under: TianoCore Contribution Agreement
The DecompressMemFvs() function in OvmfPkg/Sec/SecMain.c uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC
MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf is the library
instance that implements the LockBoxLib library class with SMRAM access
for the PEI phase.
Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
The PiSmmCpuDxeSmm driver depends on an ACPI_CPU_DATA structure from the
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ driver. The address of
this structure is communicated through the dynamic PCD
PcdCpuS3DataAddress. The data and control flows are as follows:
CpuMpDxe
BaseExtractGuidedSectionLib uses a table at the static physical address
PcdGuidedExtractHandlerTableAddress, and modules that are linked against
BaseExtractGuidedSectionLib are expected to work together on that table.
Namely, some modules can register handlers for GUIDed sections, some other
The ACPI_CPU_DATA structure is populated by
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe, which we do not plan to
import as a whole.
CpuMpDxe allocates ACPI_CPU_DATA in AcpiNVS memory (below 4GB), populates
it carefully, and passes its address to PiSmmCpuDxeSmm via a dynamic PCD,
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().
Furthermore, since our LockBox must not be selected with -D SMM_REQUIRE,
For a short introduction, jump to the last patch.
Past discussions (just what I could easily find):
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14243
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14243/focus=14330
The series is supposed to
- *build* at every stage, using
As explained in the earlier patch, PiSmmCpuDxeSmm only depends on the
header file; import it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h | 702
OvmfPkg/OvmfPkg.dec
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf (a DXE_RUNTIME_DRIVER)
implements the SMM Initial Program Loader. It produces
EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on:
- EFI_SMM_ACCESS2_PROTOCOL
(provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf),
- EFI_SMM_CONTROL2_PROTOCOL
PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
generally for all DXE_SMM_DRIVER modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/OvmfPkgIa32.dsc| 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
PiSmmCpuDxeSmm says it depends on SmmLib. The original set of APIs, from
MdePkg/Include/Library/SmmLib.h, includes:
- TriggerBootServiceSoftwareSmi()
- TriggerRuntimeSoftwareSmi()
- IsBootServiceSoftwareSmi()
- IsRuntimeSoftwareSmi()
- ClearSmi()
Edk2 only contains a Null instance for the SmmLib
Continuing the pattern seen in the previous patches, we now incorporate
code from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates
- ACPI_CPU_DATA.StackAddress,
- ACPI_CPU_DATA.StackSize.
During normal boot, CpuS3DataDxe allocates stack in the entry point for
all the APs in AcpiNVS
This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
on in its gEfiDxeSmmReadyToLockProtocolGuid callback
(SmmReadyToLockHandler(), MdeModulePkg/Core/PiSmmCore/PiSmmCore.c).
Approached on a higher level, this driver provides the SmmIo member of the
EFI_SMM_SYSTEM_TABLE2
AddReservedMemoryBaseSizeHob() should be able to set the same resource
attributes for reserved memory as AddMemoryBaseSizeHob() sets for system
memory. Add a new parameter called Cacheable to
AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we
have at the moment.
On 2015-07-24 09:39:34, Laszlo Ersek wrote:
Jordan,
On 07/24/15 14:41, Fan, Jeff wrote:
Reviewed-by: Jeff Fan jeff@intel.com
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, July 24, 2015 7:36 AM
To: edk2-de...@ml01.01.org
Cc: Yao,
Reviewed by: Daryl McDaniel edk2-li...@mc2research.org
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Scott
Duplichan
Sent: Thursday, July 23, 2015 1:19 PM
To: edk2-devel@lists.01.org
Cc: 'Daryl Mcdaniel' daryl.mcdan...@intel.com
Subject: [edk2]
On 2015-07-24 16:15:57, Daryl McDaniel wrote:
Reviewed by: Daryl McDaniel edk2-li...@mc2research.org
I added Daryl's Reviewed-by and added the patch to the svn-offline
branch:
https://github.com/tianocore/edk2-svn-offline master
-Jordan
-Original Message-
From: edk2-devel
Move to the parametrised generic GCC linker script and set 64 KB
alignment, instead of using the AARCH64 specific incremental linker
script for 64 KB alignment which is about to be removed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
60 matches
Mail list logo
