Reviewed-by: Jiewen Yao
> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, October 22, 2019 12:39 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Sean Brogan ; Yao, Jiewen
> ; Zhang, Chao B
> Subject: RE: [Patch] SecurityPkg: Fix spelling errors
>
>
> Reviewed-by:
Reviewed-by: Jian J Wang
> -Original Message-
> From: Kinney, Michael D
> Sent: Saturday, October 19, 2019 3:02 AM
> To: devel@edk2.groups.io
> Cc: Sean Brogan ; Yao, Jiewen
> ; Wang, Jian J ; Zhang, Chao B
>
> Subject: [Patch] SecurityPkg: Fix spelling errors
>
> From: Sean Brogan
Sean,
Do you have any comments from MS side?
Thanks,
Ray
> -Original Message-
> From: Wang, Sunny (HPS SW)
> Sent: Monday, October 21, 2019 8:45 PM
> To: Ni, Ray ; devel@edk2.groups.io; Gao, Zhichao
> ; pjo...@redhat.com
> Cc: Wang, Jian J ; Wu, Hao A ;
> Zeng, Star ; Gao, Liming ;
>
Just resending by correcting the edk2-staging branch name in the subject line.
Kindly review and provide your feedback.
Thanks
Ashraf
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Javeed,
> Ashraf
> Sent: Thursday, October 17, 2019 10:24 PM
> To: devel@edk2.groups.io
>
Reviewed-by: Michael D Kinney
> -Original Message-
> From: devel@edk2.groups.io On
> Behalf Of Liming Gao
> Sent: Wednesday, October 16, 2019 11:56 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D
> Subject: [edk2-devel] [Patch v3 04/11] MdePkg Base.h:
> Add definition for CLANG9
Reviewed-by: Michael D Kinney
> -Original Message-
> From: devel@edk2.groups.io On
> Behalf Of Liming Gao
> Sent: Monday, October 14, 2019 5:27 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch v2 05/11] MdePkg
> BaseIoLibIntrinsic: Remove __inline__ attribute for IO
>
Reviewed-by: Jordan Justen
On 2019-10-21 13:13:20, Laszlo Ersek wrote:
> From: Peter Jones
>
> Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
> tests check if it's defined or not. Additionally, in UefiPayloadPkg as
> well as some other trees, we define it as FALSE in
From: Sean Brogan
https://bugzilla.tianocore.org/show_bug.cgi?id=2259
Update DSC file to build all libraries and modules in
the NetworkPkg.
Cc: Siyuan Fu
Cc: Jiaxin Wu
Signed-off-by: Michael D Kinney
---
NetworkPkg/NetworkPkg.dsc | 6 ++
1 file changed, 6 insertions(+)
diff --git
From: Peter Jones
Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
tests check if it's defined or not. Additionally, in UefiPayloadPkg as
well as some other trees, we define it as FALSE in the .dsc file.
This patch changes all of the Ovmf platforms to explicitly define it
On 2019.10.21 15:39, Leif Lindholm wrote:
On Mon, Oct 21, 2019 at 03:28:37PM +0100, Pete Batard wrote:
Hi Leif,
On 2019.10.21 14:46, Leif Lindholm wrote:
On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote:
On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote:
If anything,
On 10/21/19 15:37, Liming Gao wrote:
> Shenglei:
> Those header files are added as the missing header file
> @8906f076de35b222a7d62bcf6ed1a4a2498a5791.
> Please keep them in INF file.
If we needed to add those files manually to the INF file, then:
- either the perl script
Siyuan,
One comment on this patch is that the C code is using
FixedPcdGetPool() instead of PcdGetBool(). The FixedPcdGetBool()
is only recommended when the PCD type is guaranteed to be
FixedAtBuild and the PCD value must be known at compile,
with a constant value, usually to initialize fields in
Hi Scott,
I would agree that the current logic that checks for uniqueness applies to V3+
of an EFI_FIRMWARE_IMAGE_DESCRITOR.
Below V3, the HardwareInstance field does not exist, so I agree that the
uniqueness check and ASSERT can not be done. The language around V3 that
introduced fields
On 10/21/19 10:06, Zhang, Shenglei wrote:
> Update openssl from 1.1.1b to 1.1.1d.
> Something needs to be noticed is that, there is a bug existing in the
> released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596),
> which causes build failure. So we switch the code base to a usable
>
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
-Original Message-
From: Krzysztof Koch
Sent: 12 June 2019 03:10 PM
To: devel@edk2.groups.io
Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com;
michael.d.kin...@intel.com; liming@intel.com; Sami Mujawar
; Matteo
The header in the EFI_SYSTEM_TABLE (gST) carries the UEFI Specification
version. It is filled in by the DXE Core when it produces the EFI System Table.
$ git grep EFI_SYSTEM_TABLE_REVISION
MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:126:EFI_SYSTEM_TABLE_REVISION,
When runs "ver" command in EFI Shell command line it shows UEFI specification
and revision. The question is how to find out what UEFI specification and
revision does EDK2 support?
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#49309):
From: Marvin Haeuser
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2302
The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize",
which takes the size of the buffer in bytes. Replace the currently
used MAX_DEBUG_MESSAGE_LENGTH usage, which is the buffer's length,
with the actual
On Fri, Oct 18, 2019 at 06:23:05AM +, Abner Chang wrote:
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Leif Lindholm
> > Sent: Thursday, October 3, 2019 6:03 AM
> > To: devel@edk2.groups.io; Chen, Gilbert
> > Cc: Palmer Dabbelt
>
On Mon, Oct 21, 2019 at 03:28:37PM +0100, Pete Batard wrote:
> Hi Leif,
>
> On 2019.10.21 14:46, Leif Lindholm wrote:
> > On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote:
> > > On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé
> > > wrote:
> > > > > If anything, I guess we
On Mon, Oct 21, 2019 at 03:09:58PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/21/19 1:25 PM, Pete Batard wrote:
> > Similar to what is being done in edk2-platforms, elements of the Pi 3
> > platform that can be factorized for use with the Pi 4 are factorized.
> >
> > For non-OSI this only
Hi Leif,
On 2019.10.21 14:46, Leif Lindholm wrote:
On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote:
On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote:
On 10/21/19 2:52 PM, Pete Batard wrote:
Hi Philippe,
On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
Hi Pete,
Reviewed-by: Alexei Fedorov alexei.fedo...@arm.com
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#49304): https://edk2.groups.io/g/devel/message/49304
Mute This Topic: https://groups.io/mt/36317090/21656
Group Owner:
The SRAT generator uses the configuration manager protocol
to obtain the affinity information for the GICC, GIC ITS,
Memory, Generic Initiator, etc. and generates the SRAT table.
The table generator supports ACPI 6.3, SRAT table revision 3.
The ACPI and PCI device handles of the Generic
On 10/21/19 11:58, Vitaly Cheptsov via Groups.Io wrote:
> Jiewen,
>
> We are aware of all these nuances, and you are right that both of them
> (strlcpy/strcpy_s) have their downsides. Our opinion is that strlcpy
> is more practical, but that is a personal choice, and we do nor care
> much on what
On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote:
> On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé
> wrote:
> >
> > On 10/21/19 2:52 PM, Pete Batard wrote:
> > > Hi Philippe,
> > >
> > > On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
> > >> Hi Pete,
> > >>
> > >> On
Hi Ard,
On 2019.10.21 14:24, Ard Biesheuvel wrote:
On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote:
On 10/21/19 2:52 PM, Pete Batard wrote:
Hi Philippe,
On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
Hi Pete,
On 10/21/19 1:25 PM, Pete Batard wrote:
In preparation for
Shenglei:
Those header files are added as the missing header file
@8906f076de35b222a7d62bcf6ed1a4a2498a5791.
Please keep them in INF file.
Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Zhang, Shenglei
> Sent: Monday, October 21, 2019 4:07 PM
> To:
On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote:
>
> On 10/21/19 2:52 PM, Pete Batard wrote:
> > Hi Philippe,
> >
> > On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
> >> Hi Pete,
> >>
> >> On 10/21/19 1:25 PM, Pete Batard wrote:
> >>> In preparation for adding Raspberry Pi 4
On 10/18/19 9:34 PM, Michael D Kinney wrote:
From: Sean Brogan
https://bugzilla.tianocore.org/show_bug.cgi?id=2263
Cc: Ray Ni
Signed-off-by: Michael D Kinney
---
PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c | 12 ++--
PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf |
Hi Michael,
On 10/18/19 9:15 PM, Michael D Kinney wrote:
From: Sean Brogan
Is a different patch than https://edk2.groups.io/g/devel/topic/32250614
or simply the patch author got messed up?
It should be: Antoine Cœur
https://bugzilla.tianocore.org/show_bug.cgi?id=2264
Cc: Ray Ni
Michael,
Wouldn't the current implementation ASSERT if there are different plug-in cards
by the same vendor using the same GUID in their FMP? They are managing
different hardware and have no knowledge of the existence of the other FMP
instance. Each FMP is only aware of the specific device
On 10/21/19 2:52 PM, Pete Batard wrote:
Hi Philippe,
On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
Hi Pete,
On 10/21/19 1:25 PM, Pete Batard wrote:
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform
is restructured by factorizing all the drivers and libraries that are
On 10/21/19 1:25 PM, Pete Batard wrote:
Similar to what is being done in edk2-platforms, elements of the Pi 3
platform that can be factorized for use with the Pi 4 are factorized.
For non-OSI this only applies to the Logo driver, as the Device Tree
and the Trusted Firmware are of course too
Hi Philippe,
On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote:
Hi Pete,
On 10/21/19 1:25 PM, Pete Batard wrote:
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform
is restructured by factorizing all the drivers and libraries that are
going to be commonly used by the two
Sorry for the delay and thanks for checking my question, Ray.
Since the OS recovery and platform recovery options were added to UEFI
specification at the same time, I thought we will also implement it and push
the code regardless of the OS support.
No, I didn't see a real need of using the OS
Hi Pete,
On 10/21/19 1:25 PM, Pete Batard wrote:
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform
is restructured by factorizing all the drivers and libraries that are
going to be commonly used by the two platforms.
Because much of the Pi 4 SoC is an extension of the Pi 3
Pushed as : 61bb6eeb4d93..91f98c908627
Thanks.
Regards,
Sami Mujawar
-Original Message-
From: Ard Biesheuvel
Sent: 15 October 2019 12:08 PM
To: devel@edk2.groups.io
Cc: ler...@redhat.com; Sami Mujawar ;
leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH 1/1] DynamicTablesPkg:
Similar to what is being done in edk2-platforms, elements of the Pi 3
platform that can be factorized for use with the Pi 4 are factorized.
For non-OSI this only applies to the Logo driver, as the Device Tree
and the Trusted Firmware are of course too platform specific to be
factorized.
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform
is restructured by factorizing all the drivers and libraries that are
going to be commonly used by the two platforms.
Because much of the Pi 4 SoC is an extension of the Pi 3 one this
means that almost everything, except the ACPI
Reviewed-by: Alexei Fedorov
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#49286): https://edk2.groups.io/g/devel/message/49286
Mute This Topic: https://groups.io/mt/34544264/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
Jiewen,
We are aware of all these nuances, and you are right that both of them
(strlcpy/strcpy_s) have their downsides. Our opinion is that strlcpy is more
practical, but that is a personal choice, and we do nor care much on what is
available as long as it is documented.
Our primary issues
Hi Vitaly
Before we introduce EDKII version safe string, we did investigate the behavior
of below APIs:
1) strcpy - We all know that...
2) strncpy - The problem is that this API cannot guarantee a string is NULL
terminated.
3) strlcpy - It is null terminated, but the result is truncated. That
Jiewen,
Your explanation makes good sense in the context of "This API is NOT design to
handle untrusted input.", however, I believe this is not how it is should work
or at least this is not how we would like it to behave.
In Unix world there are similar hardened interfaces, for example,
Hi Vitaly
We have discussed the ASSERT usage when we added the first version of code.
C11 standard supports runtime violation handler registration.
We investigated the behavior of
(1) MS Visual Studio - http://msdn.microsoft.com/en-us/library/bb288454.aspx
(2) SafeCLib -
Update openssl from 1.1.1b to 1.1.1d.
Something needs to be noticed is that, there is a bug existing in the
released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596),
which causes build failure. So we switch the code base to a usable
version, which is 2 commits later than the stable tag.
Liming, Jiewen,
I am personally fine to resubmit the patch changing the defaults to TRUE, but
does it actually make sense in any other environment but some special testing
platform? I cannot imagine any production platform that would need it enabled,
the only use case is to perform analysis
47 matches
Mail list logo
