Laszlo,
> -Original Message-
> From: Laszlo Ersek
> Sent: Monday, February 17, 2020 3:49 PM
> To: devel@edk2.groups.io; Wang, Jian J
> Cc: Yao, Jiewen ; Zhang, Chao B
>
> Subject: Re: [edk2-devel] [PATCH v2 00/10] Fix false negative issue in
> DxeImageVerificationHandler
>
> On
On 02/13/20 00:53, Armour, Nicholas wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2031
>
> This patch triggers the RecycleEvent for invalid ARP packets.
> Prior to this, we would just ignore invalid ARP packets,
> and never free them.
>
> Cc: Jiaxin Wu
> Cc: Maciej Rabeda
> Cc:
On 02/14/20 08:27, Wang, Jian J wrote:
>> v2 changes:
>>- Change IsCertHashFoundInDatabase to IsCertHashFoundInDbx (patch 10)
>>- Update result handling to all calling to IsCertHashFoundInDatabase
>> to be consistent (patch 6)
>>- Fix commit message and title length issue caught
On 02/17/20 06:49, tim.le...@insyde.com wrote:
> Liming --
>
> Thanks for the pointer.
>
> The reason I ask is that many users of open source projects such as EDKII
> scan the releases for CVE numbers in order to make sure that critical
> components get updated. This is due to the fact that
This patch is to check the received package length to make sure the package
has a valid length field.
Cc: Fu Siyuan
Cc: Maciej Rabeda
Signed-off-by: Wu Jiaxin
Reviewed-by: Siyuan Fu
---
NetworkPkg/Ip4Dxe/Ip4Input.c | 46 +++-
1 file changed, 37
Sorry, please ignore this patch, I will correct the commit log later.
Thanks,
Jiaxin
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Wu,
> Jiaxin
> Sent: Monday, February 17, 2020 3:36 PM
> To: devel@edk2.groups.io
> Cc: Fu, Siyuan ; Wu, Jiaxin
> Subject: [edk2-devel]
This patch is to check the received package length to make sure the package
has a valid length field.
Cc: Fu Siyuan
Cc：Maciej Rabeda
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin
Reviewed-by: Siyuan Fu
---
NetworkPkg/Ip4Dxe/Ip4Input.c | 46
ASSERT in SetTime_Conf and SetWakeupTime_Conf Consistency Test.
SCT Test expect return as Invalid Parameter.
So removed ASSERT().
Added Time Validity Checks in SetWakeupTime.
Signed-off-by: Gaurav Jain
---
EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClock.c | 8
1 file changed, 4
Gentle Reminder!!
Please review..
> -Original Message-
> From: Gaurav Jain
> Sent: Thursday, January 30, 2020 1:48 PM
> To: devel@edk2.groups.io
> Cc: Jian J Wang ; Hao A Wu ;
> Ray Ni ; Pankaj Bansal ; Gaurav
> Jain
> Subject: [PATCH 1/1] MdeModulePkg/Pci: Fixed Asserts in SCT PCIIO
On Mon, 17 Feb 2020 at 07:56, Ard Biesheuvel wrote:
>
> On Mon, 17 Feb 2020 at 07:25, Gaurav Jain wrote:
> >
> > Hi Ard
> >
> > I have also checked UEFI Shell Specification Version
> > 2.2(https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf)
> > For date command the range of valid
On Mon, 17 Feb 2020 at 07:25, Gaurav Jain wrote:
>
> Hi Ard
>
> I have also checked UEFI Shell Specification Version
> 2.2(https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf)
> For date command the range of valid years is from 1998–2099 (on page 121)
>
> So Range of valid years is
For the patch series,
Reviewed-by: Jian J Wang
Regards,
Jian
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Zurcher,
> Christopher J
> Sent: Friday, February 14, 2020 8:40 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX
> Subject: [edk2-devel] [PATCH v3
Hi Ard
I have also checked UEFI Shell Specification Version
2.2(https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf)
For date command the range of valid years is from 1998–2099 (on page 121)
So Range of valid years is conflicting in UEFI Spec and UEFI Shell Spec.
I think UEFI spec
Liming --
Thanks for the pointer.
The reason I ask is that many users of open source projects such as EDKII
scan the releases for CVE numbers in order to make sure that critical
components get updated. This is due to the fact that CVEs often need to be
reported to downstream users. The Bugzilla
Tim:
There is no special list for the security fixes. All bug fixes will be found
in Bugzilla List in stable tag wiki, such as
https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
Boot Guard is as the feature. So, it is listed in the feature planning.
Thanks
Liming
>
Hi, Nicholas
Should the signal recycle event also be added to below if condition?
if (RxData->DataLength < sizeof (ARP_HEAD)) {
//
// Restart the receiving if packet size is not correct.
//
goto RESTART_RECEIVE;
}
Best Regards
Siyuan
> -Original Message-
> From:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1989
The commit will avoid unmapping the same resource in error handling logic
for function BuildAdmaDescTable() and SdMmcCreateTrb().
For the error handling in BuildAdmaDescTable():
The error is directly related with the corresponding Map()
V5 Changes:
Add FIT address check to see if it's in valid firmware region.
V4 Changes:
Adjust EDKII_MICROCODE_SHADOW_INFO_HOB structure definition for
better alignment and understanding.
Add EFI_MICROCODE_STORAGE_TYPE_FLASH_CONTEXT structure definition.
Fix a typo in
Mike,
Sorry I don't think I totally understood what felt wrong to me, so I did a bad
job explaining my concerns. Also I don't think I was thinking enough in the
context of the C11 StdLib.
I think my concern is still the global scope of the constraint, even if we tune
it per module. For
Then the checks against 0x and 0x
should be removed.
If those checks are important, then replace with checks against
max physical address. Or if it is guaranteed to be below 4GB,
then check against that value with a clear comment for the
checks being performed.
On 2/15/20 6:33 AM, Marc-André Lureau wrote:
Hi Yao
On Thu, Feb 13, 2020 at 2:51 PM Yao, Jiewen wrote:
Hi Lureau
I don’t think we should expose the TPM Interface type via TpmCommandLib.
That is the TPM device implementation. The TPM device might use TIS/FIFO/CRB,
but there might be also
22 matches
Mail list logo
