Hi all,
Thanks for the comments.
I agree with the change.
I will update the term in next version of the patch set.
Thanks
Zhiguang
> -Original Message-
> From: Ma, Maurice
> Sent: Wednesday, June 9, 2021 11:08 AM
> To: Ni, Ray ; Dong, Guo ;
> Rangarajan, Ravi P
> Cc: Liming Gao ;
On Wed, 26 May 2021 at 12:12, Nhi Pham wrote:
>
> From: Vu Nguyen
>
> The roles of this driver:
> * Consume PcieCoreLib to initialize all enable PCIe controllers.
> * Produce neccessary protocols like RootBridgeIo an ResourceAllocation
> which will be used later by PciBus.
>
> Cc: Thang Nguyen
Add defines for the config space offsets for virtio 1.0 mmio transport.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/IndustryStandard/Virtio10.h | 12
1 file changed, 12 insertions(+)
diff --git a/OvmfPkg/Include/IndustryStandard/Virtio10.h
Add support for virtio 1.0 to the mmio transport. virtio 0.9.5 uses
page size, page frame number and a fixed layout for the ring. virtio
1.0 uses the physical addresses for base address, used bits and
available bits instead.
The ring layout is not changed, so a 0.9.5 compatible layout is used
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. Which is a
valid argument. But IMHO isn't a good
Hi, Ray,
Yes, I agree. PLD might cause confusion sometimes.
Maybe we just use the full name UNIVERSAL_PAYLOAD instead ?
Thanks
Maurice
> -Original Message-
> From: Ni, Ray
> Sent: Tuesday, June 8, 2021 19:58
> To: Ma, Maurice ; Dong, Guo
> ; Rangarajan, Ravi P
> Cc: Liming Gao ;
Thank you! Shengfeng
Reviewed-by: Jiewen Yao
I recommend to wait for *1 week*, to see if anyone has concern on size change.
Thank you
Yao Jiewen
> -Original Message-
> From: xueshengfeng
> Sent: Tuesday, June 8, 2021 12:31 PM
> To: devel@edk2.groups.io; Yao, Jiewen ; Wang, Jian J
>
Mike,
Thanks for the recommendation.
Just check https://en.wikipedia.org/wiki/Programmable_logic_device and it seems
to me PLD is a very common term in EE world. FPGA is a kind of PLD.
Maurice, Ravi, Guo, comments?
Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io On
Add Liming to review as it is a change related to variable.
Thanks,
Zhichao
> -Original Message-
> From: kenlautn...@gmail.com
> Sent: Saturday, June 5, 2021 4:13 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Gao, Zhichao ; Ni, Ray
> Subject: [PATCH v1 1/1]
On 06/09/2021 12:01 AM, James Bottomley wrote:
> It looks like I'll be travelling that day, but should be able to attend at
> least the
> first 45 minutes of the design review from the airport lounge.
>
Thanks much James!
> On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
On 06/09/2021 3:33 AM, Laszlo wrote:
> (Min Xu got dropped from the CC list for some reason, at *some* point in this
> sub-thread! Not sure when. Re-adding him.)
>
> Commenting on excerpts:
>
> On 06/08/21 18:01, James Bottomley wrote:
>
> > On TdMailbox and TdHob, we already have two SEV pages
That remembers me why did I do my mastering thesys using a real hardware :)
Rafael
Em ter, 8 de jun de 2021 17:25, Leif Lindholm escreveu:
> 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,
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 phase is considered the "HOB producer phase",
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 turns out not being the ideal way, that's just the way it
(Min Xu got dropped from the CC list for some reason, at *some* point in
this sub-thread! Not sure when. Re-adding him.)
Commenting on excerpts:
On 06/08/21 18:01, James Bottomley wrote:
> On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and
> since TDX and SEV is an
So I just might have to go with USB audio (the basic audio device
class) since no code in QEMU for VirtIO audio has actually been
committed upstream. Perusing the qemu code (specifically this:
https://github.com/qemu/qemu/blob/master/hw/usb/dev-audio.c) it
appears that Qemu implements v. 1.0 of
On 6/8/21 1:01 PM, Laszlo Ersek via groups.io wrote:
>
>> Now I think about it maybe we should leave the driver where it is
>> because OvmfPkgX64.dsc does not need to deal with the attestation etc.
>> But we need to create a driver that can install the EFI configuration
>> table for the SNP
On 06/08/21 17:43, Brijesh Singh wrote:
>
> On 6/8/21 4:20 AM, Laszlo Ersek via groups.io wrote:
>>
>> I thought the secrets page was entirely opaque to the guest firmware;
>> i.e., all the guest firmware would do with it is (a) cover it with an
>> allocation in SecretPei, (b) forward it to the
On 06/08/21 15:51, Brijesh Singh wrote:
>
> On 6/8/21 3:17 AM, Laszlo Ersek wrote:
>>
(3) Actually, no.
This patch should be reduced to the following files only:
- OvmfPkg/PlatformPei/AmdSev.c
- OvmfPkg/PlatformPei/PlatformPei.inf
and the following changes
I see use of the abbreviation PLD in this series.
PLD is sometimes interpreted as Programmable Logic Device.
Given this is for Universal Payload, I recommend using UNIVERSAL_PAYLOAD or
PAYLOAD as appropriate.
Mike
> -Original Message-
> From: Liu, Zhiguang
> Sent: Friday, June 4,
On Thu, 2021-06-03 at 13:51 +, Yao, Jiewen wrote:
> Hi, All
> We plan to do a design review for TDVF in OVMF package.
>
>
> The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11)
> is now available in blow link:
> https://edk2.groups.io/g/devel/files/Designs/2021/0611.
>
> The
On 06/08/21 14:49, Ard Biesheuvel wrote:
> On Tue, 8 Jun 2021 at 12:59, Laszlo Ersek wrote:
>>
>> Ard,
>>
>> do you have any comments please, on the topic at the bottom?
>>
>> My comments follow:
>>
>> On 06/08/21 11:57, Dov Murik wrote:
>>>
>>>
>>> On 04/06/2021 14:26, 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:
>>> I started working on that, and managed to remove all QemuFwCfg*
>>> calls in the main path of QemuLoadKernelImage (so far working on
>>> X86QemuLoadImageLib.c). That works
On 6/8/21 4:20 AM, Laszlo Ersek via groups.io wrote:
>
> I thought the secrets page was entirely opaque to the guest firmware;
> i.e., all the guest firmware would do with it is (a) cover it with an
> allocation in SecretPei, (b) forward it to the guest OS via a UEFI
> system config table in
On 06/08/21 14:27, Xu, Min M wrote:
> On 06/04/2021 12:12 AM, Laszlo wrote:
>> But it counts as an absolute disaster nowadays, and should not be revived in
>> any platform. If you don't have pflash in TDX guests, just accept that you
>> won't have non-volatile variables. And link
On 6/8/21 3:49 AM, Laszlo Ersek wrote:
> On 06/07/21 15:37, Brijesh Singh wrote:
>
>> Also, I was trying to avoid the cases where the malicious hypervisor
>> changing the feature value after the GHCB negotiation is completed.
>> e.g, during the reset vector they give us one feature value and
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.
Checking address will let TF-A communicate failed to MM. So remove
Many of the cache definitions in ArmLibPrivate.h are being used outside
of ArmLib, in Universal/Smbios. Move them into ArmLib.h to make them
public, and remove the include of ArmLibPrivate.h from files in
Universal/Smbios.
Signed-off-by: Rebecca Cran
---
ArmPkg/Include/Library/ArmLib.h
On 6/8/21 3:17 AM, Laszlo Ersek wrote:
>
>>> (3) Actually, no.
>>>
>>> This patch should be reduced to the following files only:
>>>
>>> - OvmfPkg/PlatformPei/AmdSev.c
>>> - OvmfPkg/PlatformPei/PlatformPei.inf
>>>
>>> and the following changes should be dropped completely:
>>>
>>> -
Introduce the NETWORK_ISCSI_MD5_ENABLE feature test macro for NetworkPkg.
When explicitly set to FALSE, remove MD5 from IScsiDxe's CHAP algorithm
list.
Set NETWORK_ISCSI_MD5_ENABLE to TRUE by default, for compatibility
reasons. Not just to minimize the disruption for platforms that currently
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
Cc: Maciej Rabeda
Cc: Philippe Mathieu-Daudé
Cc: Siyuan
Introduce the "mChapHash" table, containing the hash algorithms supported
for CHAP. Hash algos listed at the beginning of the table are preferred by
the initiator.
In ISCSI_CHAP_STEP_ONE, send such a CHAP_A value that is the
comma-separated, ordered list of algorithm identifiers from "mChapHash".
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Repo: https://pagure.io/lersek/edk2.git
Branch: iscsi_sha256_bz3355
Please find the Feature Request described in comment#0 of the BZ.
The patch series depends on:
[edk2-devel] [PUBLIC edk2 PATCH v2 00/10]
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 encodings alike), and (b) *processing*
binary digest buffers
RFC 7143 explains that a single iSCSI session may use multiple TCP
connections. The first connection established is called the leading
connection. The login performed on the leading connection is called the
leading login. Before the session is considered full-featured, the leading
login must
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 functional changes.
Cc: Jiaxin Wu
Cc: Maciej
On Tue, 8 Jun 2021 at 12:59, Laszlo Ersek wrote:
>
> Ard,
>
> do you have any comments please, on the topic at the bottom?
>
> My comments follow:
>
> On 06/08/21 11:57, Dov Murik wrote:
> >
> >
> > On 04/06/2021 14:26, Laszlo Ersek wrote:
> >> On 06/04/21 12:30, Dov Murik wrote:
> >>
> >
> > ...
This patch is upstreamed by the commit-id:
https://github.com/tianocore/edk2-test/commit/b68e40293485ce3c6bf50294900d068bbaeba213
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76211): https://edk2.groups.io/g/devel/message/76211
Mute
Reviewed-by: G Edhaya Chandran
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76210): https://edk2.groups.io/g/devel/message/76210
Mute This Topic: https://groups.io/mt/81521738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
On 06/04/2021 12:12 AM, Laszlo wrote:
> (22) EmuVariableFvbRuntimeDxe
>
> Ouch, this is an unpleasant surprise.
>
> First, if you know for a fact that pflash is not part of the *board* in any
> TDX
> setup, then pulling
>
> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
>
The IScsiHexToBin() function documents the EFI_BUFFER_TOO_SMALL return
condition, but never actually checks whether the decoded buffer fits into
the caller-provided room (i.e., the input value of "BinLength"), and
EFI_BUFFER_TOO_SMALL is never returned. The decoding of "HexStr" can
overflow
IScsiDxe (that is, the initiator) receives two hex-encoded strings from
the iSCSI target:
- CHAP_C, where the target challenges the initiator,
- CHAP_R, where the target answers the challenge from the initiator (in
case the initiator wants mutual authentication).
Accordingly, we have two
The IScsiHexToBin() function has the following parser issues:
(1) If the *subject sequence* in "HexStr" is empty, the function returns
EFI_SUCCESS (with "BinLength" set to 0 on output). Such inputs should
be rejected.
(2) The function mis-handles a "HexStr" that ends with a stray nibble.
IScsiBinToHex() is called for encoding:
- the answer to the target's challenge; that is, CHAP_R;
- the challenge for the target, in case mutual authentication is enabled;
that is, CHAP_C.
The initiator controls the size of both blobs, the sizes of their hex
encodings are correctly calculated
We'll need further return values for IScsiHexToBin() in a subsequent
patch; make room for them in the leading comment block of the function.
While at it, rewrap the comment block to 80 characters width.
No functional changes.
Cc: Jiaxin Wu
Cc: Maciej Rabeda
Cc: Philippe Mathieu-Daudé
Cc:
Sort the library class dependencies in the #include directives and in the
INF file. Remove the DpcLib class from the #include directives -- it is
not listed in the INF file, and IScsiDxe doesn't call either DpcLib API
(QueueDpc(), DispatchDpc()). No functional changes.
Cc: Jiaxin Wu
Cc: Maciej
The "ISCSI_CHAP_AUTH_DATA.OutChallenge" field is declared as a UINT8 array
with ISCSI_CHAP_AUTH_MAX_LEN (1024) elements. However, when the challenge
is generated and formatted, only ISCSI_CHAP_RSP_LEN (16) octets are used
in the array.
Change the array size to ISCSI_CHAP_RSP_LEN, and remove the
The ISCSI_CHAP_AUTH_MAX_LEN macro is defined with value 1024.
The usage of this macro currently involves a semantic (not functional)
bug, which we're going to fix in a subsequent patch, eliminating
ISCSI_CHAP_AUTH_MAX_LEN altogether.
For now, remove the macro's usage from all
Considering IScsiBinToHex():
> if (((*HexLength) - 3) < BinLength * 2) {
> *HexLength = BinLength * 2 + 3;
> }
the following subexpressions are problematic:
(*HexLength) - 3
BinLength * 2
BinLength * 2 + 3
The first one may wrap under zero, the latter two may wrap over
Working with overlong lines is difficult for me; rewrap the CHAP-related
source files in IScsiDxe to 80 characters width. No functional changes.
Cc: Jiaxin Wu
Cc: Maciej Rabeda
Cc: Philippe Mathieu-Daudé
Cc: Siyuan Fu
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by:
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() function.
This posting corresponds to:
On 08/06/2021 13:59, Laszlo Ersek wrote:
> Ard,
>
> do you have any comments please, on the topic at the bottom?
>
> My comments follow:
>
> On 06/08/21 11:57, Dov Murik wrote:
>>
>>
>> On 04/06/2021 14:26, Laszlo Ersek wrote:
>>> On 06/04/21 12:30, Dov Murik wrote:
>>>
>>
>> ...
>>
On Wed, May 26, 2021 at 17:07:11 +0700, Nhi Pham wrote:
> From: Vu Nguyen
>
> This change is to produce RNG protocol which is required by several
> modules.
>
> Cc: Thang Nguyen
> Cc: Chuong Tran
> Cc: Phong Vo
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Cc: Ard Biesheuvel
> Cc: Nate
Hi Vikas,
Please resubmit this set, following the instructions set out by
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers
as I requested for your previous set.
Best Regards,
Leif
On Tue, Jun 01, 2021 at 19:20:30 +0530,
Ard,
do you have any comments please, on the topic at the bottom?
My comments follow:
On 06/08/21 11:57, Dov Murik wrote:
>
>
> On 04/06/2021 14:26, Laszlo Ersek wrote:
>> On 06/04/21 12:30, Dov Murik wrote:
>>
>
> ...
>
>>>
[Ard, please see this one question:]
- A major
On 04/06/2021 14:26, Laszlo Ersek wrote:
> On 06/04/21 12:30, Dov Murik wrote:
>
...
>>
>>> [Ard, please see this one question:]
>>>
>>> - A major complication for hashing all three of: kernel, initrd,
>>> cmdline, is that the *fetching* of this triplet is split between two
>>> places.
On 06/07/21 19:33, Brijesh Singh wrote:
>
> On 6/7/21 7:48 AM, Laszlo Ersek wrote:
>> On 06/07/21 14:26, Laszlo Ersek wrote:
>>> On 05/27/21 01:11, Brijesh Singh wrote:
BZ:
On Fri, Jun 4, 2021 at 11:42 AM Zhiguang Liu wrote:
>
> 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
On 06/07/21 17:58, Brijesh Singh wrote:
>
> On 6/7/21 7:26 AM, Laszlo Ersek wrote:
>> On 05/27/21 01:11, Brijesh Singh wrote:
>>> BZ:
>>>
On 06/07/21 15:37, Brijesh Singh wrote:
> Also, I was trying to avoid the cases where the malicious hypervisor
> changing the feature value after the GHCB negotiation is completed.
> e.g, during the reset vector they give us one feature value and change
> them during SEC or PEI or DXE instances
Pushed as 7bf73ecc3c47..442dfd5da647
Thanks.
Regards,
Sami Mujawar
On 19/05/2021 02:34 PM, Chandni Cherukuri wrote:
As per ACPI specification, only the head of the list needs to be
listed as a resources by a processore node, as cache node itself
contains a link to the next level of cache.
On 06/07/21 15:00, Brijesh Singh wrote:
> Hi Laszlo,
>
>
> On 6/7/21 6:20 AM, Laszlo Ersek via groups.io wrote:
>> On 06/04/21 16:15, Laszlo Ersek wrote:
>>> On 05/27/21 01:10, Brijesh Singh wrote:
BZ:
Thank you for your quick reply, comments inline.
On 08.06.21 05:10, Ni, Ray wrote:
Marvin,
Comments below.
+EFI_STATUS
+ProcessRelocation32 (
+ IN Elf32_Rela*Rela,
+ IN UINT32RelaSize,
+ IN UINT32RelaEntrySize,
+ IN UINT32
64 matches
Mail list logo
