Reviewed-by: Ray Ni
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, June 9, 2021 5:37 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Gao, Zhichao ; Ni, Ray
> Subject: [PATCH] MdeModulePkg: Fix device path when the boot manager
> menu is from different FV
On Tue, 8 Jun 2021 at 16:21, Ming Huang wrote:
>
> TF-A: TrustedFirmware-a
> SPM: Secure Partition Manager(MM)
>
> For AArch64, when SPM enable in TF-A, TF-A may communicate to MM
> with buffer address (PLAT_SPM_BUF_BASE). The address is different
> from PcdMmBufferBase which use in edk2.
Then
On 09.06.21 11:49, Ni, Ray wrote:
Thank you for your quick reply, comments inline.
I have to be quick because my project depends on the check-in of this code
Sure, so thanks a lot for taking the time!
One non-trivial comment at the bottom.
+ for ( Index = 0
+ ; RelaEntrySize *
On 06/08/21 23:36, Tom Lendacky wrote:
> On 6/8/21 3:49 AM, Laszlo Ersek wrote:
>> On 06/07/21 15:37, Brijesh Singh wrote:
>>
>>
> ...
>
>> ... But maybe I just need to accept that we have to repurpose
>> SEC_SEV_ES_WORK_AREA, considering it a super-early "HOB list" of sorts.
>> Same as the PEI
On 06/08/21 22:25, Leif Lindholm wrote:
> Hi Ethin,
>
> Adapting and overcoming is very much the point of GSoC.
> The purpose of this project was always to bring portable audio support
> to EDK2, and longer-term the UEFI specification. Virtio was just the
> ideal means to that end.
>
> If it
On 6/8/21 3:06 PM, Laszlo Ersek wrote:
> In the next patches, we'll need more room for various macro and parameter
> names. For maintaining the current visual alignments, insert some
> horizontal whitespace in preparation. "git show -b" produces no output for
> this patch; the patch introduces no
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3441
When the boot manager menu is from different FV, the current logic still use the
device path of the FV as the module links to this library
Cc: Jian J Wang
Cc: Hao A Wu
Cc: Zhichao Gao
Cc: Ray Ni
Signed-off-by: Zhiguang Liu
---
> Thank you for your quick reply, comments inline.
I have to be quick because my project depends on the check-in of this code
> >>> + for ( Index = 0
> >>> + ; RelaEntrySize * Index < RelaSize
> >> Overflow?
> >>
> > Will change from:
> >RelaEntrySize * Index < RelaSize
> > to:
> >
Hi Laszlo,
On 6/8/21 3:06 PM, Laszlo Ersek wrote:
> IScsiDxe uses the ISCSI_CHAP_RSP_LEN macro for expressing the size of the
> digest (16) that it solely supports at this point (MD5).
> ISCSI_CHAP_RSP_LEN is used for both (a) *allocating* digest-related
> buffers (binary buffers and hex
This is the fix of the regression issue at c6b872c6.
Based on ELF spec, readonly alloc section is .rodata section. It is requried.
This fix is to add back original check logic for ELF section. Now,
the readonly alloc section and execute alloc section are regarded as .text
section.
On 6/8/21 3:06 PM, Laszlo Ersek wrote:
> Insert a SHA256 CHAP_HASH structure at the start of "mChapHash".
>
> Update ISCSI_CHAP_MAX_DIGEST_SIZE to SHA256_DIGEST_SIZE (32).
>
> This enables the initiator and the target to negotiate SHA256 for CHAP, in
> preference to MD5.
>
> Cc: Jiaxin Wu
>
On 06/09/21 02:58, Xu, Min M wrote:
> On 06/09/2021 3:33 AM, Laszlo wrote:
>> On 06/08/21 18:01, James Bottomley wrote:
>>> On your slide 13 Question: "Open: How will the QEMU find the metadata
>>> location?" can't you just use the mechanism for SEV that's already
>>> upstream in both QEMU and
On 6/9/21 7:05 AM, Gerd Hoffmann wrote:
> virtio-mmio support in ovmf seems to be the unloved child. The final
> virto-1.0 specification was published five(!) years ago, nevertheless
> the mmio transport doesn't support it yet ...
>
> Some people argue that it has been obsoleted by virtio-pci.
On 06/09/21 12:43, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> On 6/8/21 3:06 PM, Laszlo Ersek wrote:
>> IScsiDxe uses the ISCSI_CHAP_RSP_LEN macro for expressing the size of the
>> digest (16) that it solely supports at this point (MD5).
>> ISCSI_CHAP_RSP_LEN is used for both (a) *allocating*
On Wed, 2021-06-09 at 02:01 +, Xu, Min M wrote:
> On 06/09/2021 12:01 AM, James Bottomley wrote:
[...]
> > On slide 19, the mucking with the reset vector really worries me
> > because we don't have that much space to play with. Given that
> > you're starting in 32 bit mode and can thus enter
In order to support measured SEV boot with kernel/initrd/cmdline, we'd
like to have one place that reads those blobs; in the future we'll add
the measurement and verification in that place.
We already have a synthetic filesystem (QemuKernelLoaderFs) which holds
three files: "kernel", "initrd",
This reverts commit efc52d67e1573ce174d301b52fa1577d552c8441.
Manually fixed conflicts in:
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
Note that besides re-exposing the kernel command line as a file in the
synthetic filesystem, we also revert back to AllocatePool instead of
Remove the QemuFwCfgLib interface used to read the QEMU cmdline
(-append argument) and the initrd size. Instead, use the synthetic
filesystem QemuKernelLoaderFs which has three files: "kernel", "initrd",
and "cmdline".
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: James Bottomley
Make it clear that X86QemuLoadImageLib relies on fw_cfg; prepare the
ground to add a warning about the incompatibility with boot verification
process.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: James Bottomley
Cc: Tobin Feldman-Fitzthum
Signed-off-by: Dov Murik
---
On 08/06/2021 18:59, Laszlo Ersek wrote:
> On 06/08/21 14:09, Dov Murik wrote:
>> On 08/06/2021 13:59, Laszlo Ersek wrote:
>>> On 06/08/21 11:57, Dov Murik wrote:
>
>>
>> But if we go with (1) -- do you (and Ard) prefer:
>>
>> (a) leave X86QemuLoadImageLib as it is in master;
>>
>> -or-
>>
>>
On Wed, Jun 09, 2021 at 11:50:07 +0700, Nhi Pham wrote:
> > > diff --git
> > > a/Silicon/Ampere/AmpereAltraPkg/Library/MailboxInterfaceLib/MailboxInterfaceLib.c
> > >
> > > b/Silicon/Ampere/AmpereAltraPkg/Library/MailboxInterfaceLib/MailboxInterfaceLib.c
> > > new file mode 100644
> > > index
Didn't know you could do USB passthrough, that would be useful -- I do
have a USB mixer that I could test. And I could easily get USB
headphones as well.
On 6/9/21, Leif Lindholm wrote:
> On Wed, Jun 09, 2021 at 13:25:16 +0100, Michael Brown wrote:
>> On 09/06/2021 11:57, Laszlo Ersek wrote:
>>
On 06/09/21 14:25, Dov Murik wrote:
>
>
> On 08/06/2021 18:59, Laszlo Ersek wrote:
>> On 06/08/21 14:09, Dov Murik wrote:
>>> On 08/06/2021 13:59, Laszlo Ersek wrote:
On 06/08/21 11:57, Dov Murik wrote:
>>
>
>>>
>>> But if we go with (1) -- do you (and Ard) prefer:
>>>
>>> (a) leave
Hi Leif,
It's just fine. But I hope this patch will be pushed before
edk2-platforms to prevent compile error.
Regards,
Vu
On 6/4/2021 20:43, Leif Lindholm wrote:
Hi Vu,
For this set:
Reviewed-by: Leif Lindholm
Is there any value to you in me pushing this before the edk2-platforms
set
On Wed, 2021-06-09 at 13:00 +0200, Laszlo Ersek wrote:
> On 06/09/21 02:58, Xu, Min M wrote:
> > On 06/09/2021 3:33 AM, Laszlo wrote:
> > > On 06/08/21 18:01, James Bottomley wrote:
> > > > On your slide 13 Question: "Open: How will the QEMU find the
> > > > metadata location?" can't you just use
On 09/06/2021 11:57, Laszlo Ersek wrote:
I'm uneducated about the "deliverables" in GSoC, but in general I'd
suggest narrowing down the scope as much as possible. I don't know how
hard it is to program USB audio, but if QEMU provides a good device
model for that, out of the box, I would
On Wed, Jun 09, 2021 at 13:25:16 +0100, Michael Brown wrote:
> On 09/06/2021 11:57, Laszlo Ersek wrote:
> > I'm uneducated about the "deliverables" in GSoC, but in general I'd
> > suggest narrowing down the scope as much as possible. I don't know how
> > hard it is to program USB audio, but if
On 06/09/21 14:18, Dov Murik wrote:
> Make it clear that X86QemuLoadImageLib relies on fw_cfg; prepare the
> ground to add a warning about the incompatibility with boot verification
> process.
>
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: James Bottomley
> Cc: Tobin
On 06/08/21 14:12, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
> Repo: https://pagure.io/lersek/edk2.git
> Branch: iscsi_overflow_bz3356
>
> The main goal of this series is to fix a remotely exploitable buffer
> overflow in the IScsiHexToBin()
On 6/8/21 06:58, Leif Lindholm wrote:
On Wed, May 26, 2021 at 17:07:24 +0700, Nhi Pham wrote:
Adds DSC and FDF files to support the LinuxBoot build. Some PEI/DXE
drivers are not added into the target build as they are not required for
booting to the LinuxBoot Shell.
Please note that we MUST
On 09/06/21 16:28, James Bottomley wrote:
That would cut across the ApEntrypoint and the guidedStructureEnd.
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit
On 06/09/21 18:01, Ard Biesheuvel wrote:
> On Wed, 9 Jun 2021 at 17:57, Laszlo Ersek wrote:
>>
>> We currently require QEMU choco package version 2020.08.14 (from commit
>> 3ab9d60fcbe7), in "OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml".
>> Said package version references the following
On 6/8/21 06:50, Leif Lindholm wrote:
On Wed, May 26, 2021 at 17:07:22 +0700, Nhi Pham wrote:
The PlatformBootManagerLib library derived from
ArmPkg/Library/PlatformBootManagerLib.
This implementation registers only a common GUID for LinuxBoot Payload
("D834A5AD-459C-4AED-B0D0-8CBCB28838D7")
On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote:
> On 09/06/21 16:28, James Bottomley wrote:
> > That would cut across the ApEntrypoint and the guidedStructureEnd.
> > However, nothing says anything in the reset vector guided structure
> > has to be data ... so it could equally well be
We currently require QEMU choco package version 2020.08.14 (from commit
3ab9d60fcbe7), in "OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml".
Said package version references the following URLs:
https://community.chocolatey.org/packages/Qemu/2020.08.14#files
->
On Wed, 9 Jun 2021 at 17:57, Laszlo Ersek wrote:
>
> We currently require QEMU choco package version 2020.08.14 (from commit
> 3ab9d60fcbe7), in "OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml".
> Said package version references the following URLs:
>
>
Hi Guo,
Thanks for the comments.
I described the reason in the V2 commint message:
Explicitly define some PCDs as DynamicEx, or their default type will be
Dynamic
Thanks
Zhiguang
> -Original Message-
> From: Dong, Guo
> Sent: Thursday, June 10, 2021 11:04 AM
> To: Liu, Zhiguang ;
Memory buffer that is allocated by malloc() and realloc() will be
shifted by 8 bytes because Oniguruma keeps its memory signature. This 8
bytes shift is not handled while calling free() to release memory. Add
free() function to check Oniguruma signature before release memory
because memory buffer
> > Without the ParseStatus field, callee cannot know whether ParseElfImage()
> is called.
>
> It can by function contracts, the caller guarantees it. I.e. with the PE
> library I linked, no other function must be called before the init function.
> Your "ParseElfImage" function is very similar.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
This change updated calculation routine for MM communication in PiSmmIpl.
It removes ambiguity brought in by UINTN variables from this routine and
paves way for updating definition of field MessageLength in
EFI_MM_COMMUNICATE_HEADER to
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
This change replaced the calculation of communication buffer size from
explicitly adding the size of each member with the OFFSET macro function.
This will make the structure field defition change transparent to
consumers.
Cc: Jian J Wang
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430
The MessageLength field of EFI_MM_COMMUNICATE_HEADER, as a generic
definition, could be used for both PEI and DXE MM communication. On a
system that supports PEI MM launch, but
From: Sean Brogan
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3443
Existing implementation could modify class global data that causes
potential incorrect file mask to be used for execution of plugin.
This change switches class variable to be tuple so that it cannot be
accidently
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3443
Current spell check routine on CI build pipelines is ignoring some files
incorrectly.
The issue is class variable, STANDARD_PLUGIN_DEFINED_PATHS from
SpellCheck.py, is a list. In a local function the list is assigned to a
local variable,
V1:
Currently, BDS driver will link a PlatformBootManagerLib, which contains
platform
sepcific logic. This patch get the platform specific logic from a protocol, so
that
platform logic for Boot manager can be in another binary.
V2:
Add function comments in PlatformBootManagerOverride.h
V3:
Hi Patrick
Thanks for catching this issue.
I updated the code, and you can find the code below
https://github.com/LiuZhiguang001/edk2/tree/UniversalPayloadHeaders_v4
Please help confirm.
Thanks
Zhiguang
> -Original Message-
> From: Patrick Rudolph
> Sent: Tuesday, June 8, 2021 5:21 PM
Reviewed-by: Guo Dong
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, June 9, 2021 6:33 PM
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Dong, Guo
> ; You, Benjamin
> Subject: [Patch V4 6/9] UefiPayloadPkg: Creat gPldSmbiosTableGuid Hob
>
> From SysTableInfo Hob, get
Reviewed-by: Guo Dong
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, June 9, 2021 6:33 PM
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Dong, Guo
> ; You, Benjamin ; Ni, Ray
>
> Subject: [Patch V4 9/9] UefiPayloadPkg: Creat gPldAcpiTableGuid Hob
>
> From SysTableInfo
This patch 1) changed PCD type from Dynamic to DynamicEX 2) added 3 PCDs.
It would be great if you could describe why 3 PCDs are added in the commit
message.
With that:
Reviewed-by: Guo Dong
Thanks,
Guo
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, June 9, 2021 6:38
Ken:
I add my comment below. Besides, some modules in MdeModulePkg still
consumes VariableLock, such as UefiBootManagerLib, PcdDxe. Have you plan to
fix them also?
> -邮件原件-
> 发件人: kenlautn...@gmail.com
> 发送时间: 2021年6月10日 7:39
> 收件人: devel@edk2.groups.io
> 抄送: Jian J Wang ; Hao A Wu
> ;
V1:
If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table (starting with
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
is contained by a single gEfiAcpiTableGuid HOB.
V2:
If error
>From SysTableInfo Hob, get ACPI table address, and creat gPldAcpiTableGuid Hob
to store it. Remove diretly adding ACPI table to ConfigurationTable.
Dxe ACPI driver will parse it and install ACPI table from Guid Hob.
Cc: Maurice Ma
Cc: Guo Dong
Cc: Benjamin You
Cc: Ray Ni
Signed-off-by:
>From SysTableInfo Hob, get Smbios table address, and creat gPldSmbiosTableGuid
>Hob
to store it. Remove diretly adding smbios table to ConfigurationTable.
Dxe module SmbiosDxe will parse it and install smbios table from it.
Cc: Maurice Ma
Cc: Guo Dong
Cc: Benjamin You
Reviewed-by: Guo Dong
V1:
The default EfiSmbiosProtocol operates on an empty SMBIOS table.
The SMBIOS tables are provided by the bootloader on UefiPayloadPkg.
Scan for existing tables in SmbiosDxe and load them if they seem valid.
This fixes the settings menu not showing any hardware information, instead
only "0 MB
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Jian J Wang
Cc: Hao A Wu
Reviewed-by: Hao A Wu
Signed-off-by: Zhiguang Liu
---
MdeModulePkg/Include/UniversalPayload/AcpiTable.h | 30
++
MdeModulePkg/MdeModulePkg.dec | 3 +++
2 files changed, 33
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Jian J Wang
Cc: Hao A Wu
Reviewed-by: Hao A Wu
Signed-off-by: Zhiguang Liu
---
MdeModulePkg/Include/UniversalPayload/PciRootBridges.h | 91
+++
V1:
Add Universal Payload general definition header file according to
Universal Payload's documentation
V2:
Add a macro function to check the Revision
V4:
The documentation link https://universalpayload.github.io/documentation/ is
added
Change the term "PLD" to "UNIVERSAL_PAYLOAD".
Cc: Michael
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Jian J Wang
Cc: Hao A Wu
Reviewed-by: Hao A Wu
Signed-off-by: Zhiguang Liu
---
MdeModulePkg/Include/UniversalPayload/SmbiosTable.h | 30
++
MdeModulePkg/MdeModulePkg.dec | 6 ++
2 files changed,
UefiPayload parse gPldPciRootBridgeInfoGuid Guid Hob to retrieve PCI root
bridges
information. gPldPciRootBridgeInfoGuid Guid Hob should be created by Bootloader.
Cc: Maurice Ma
Cc: Guo Dong
Cc: Benjamin You
Signed-off-by: Zhiguang Liu
---
V1:
This patch set is based on Universal Payload on
https://universalpayload.github.io/documentation/payload-interfaces/index.html
This patch set introduce one general header, three different hob types and how
Universal Payload consume these hobs.
V2:
Move all the header files and Guid define
On 6/9/21 3:10 PM, Ard Biesheuvel wrote:
> On Tue, 8 Jun 2021 at 16:21, Ming Huang wrote:
>>
>> TF-A: TrustedFirmware-a
>> SPM: Secure Partition Manager(MM)
>>
>> For AArch64, when SPM enable in TF-A, TF-A may communicate to MM
>> with buffer address (PLAT_SPM_BUF_BASE). The address is
V1:
When passing PCD database from Edk2 boot loader to Universal Payload, the local
token number in boot loader PCD database can be different with that in Payload
PCD database.
Dynamic PCD directly use local token number, while DynamicEx will search token
number
by Guid and ExTokenNumber, which
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
This change replaced the calculation of communication buffer size from
explicitly adding the size of each member with the OFFSET macro function.
This will make the structure field defition change transparent to
consumers.
Cc: Jian J Wang
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430
In PI Spec v1.7 Errata A, Vol.4, Sec 5.7 MM Communication Protocol, the
MessageLength field of EFI_MM_COMMUNICATE_HEADER (also derived as
EFI_SMM_COMMUNICATE_HEADER) is currently defined as type UINTN.
But this structure, as a generic
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430
This change includes specification update markdown file that describes
the proposed PI Specification v1.7 Errata A in detail and potential
impact to the existing codebase.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Cc: Andrew
65 matches
Mail list logo
