Hi Chasel,
Looks good! This is mildly unrelated to your change, but could you put a
comment on the following line that informs the reader that 1 == API Mode?
if (PcdGet8 (PcdFspModeSelection) == 1) {
Once that is done... Reviewed-by: Nate DeSimone
-Original Message-
From: Chiu,
On Fri, 12 Apr 2019 at 16:31, Laszlo Ersek wrote:
>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Repo: https://github.com/lersek/edk2.git
> Branch: covscan_bz_1710
>
> "covscan" is an internal service at Red Hat that lets associates run
> static analysis tools on
Sync SECTION_SIZE() and EFI_COMMON_SECTION_HEADER_UNION from MdePkg to
BaseTools, from an earlier patch in this series.
Cc: Bob Feng
Cc: Liming Gao
Cc: Yonghong Zhu
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Signed-off-by: Laszlo Ersek
---
The IS_SECTION2() function-like macro duplicates the SECTION_SIZE()
calculation, just to compare the computed size against 0xFF. Invoke
SECTION_SIZE() instead; only preserve the comparison.
Cc: Liming Gao
Cc: Michael D Kinney
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
RH covscan emits the following false positive:
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:182:14:
> warning: Dereference of undefined pointer value
> #Status = FwVol->ReadSection (
> # ^~
>
RH covscan justifiedly reports a path through InstallXenTables() where
DsdtTable can technically remain NULL.
If this occurs in practice, then the guest and the VMM are out of sync on
the interface contract. Catch the situation with a code snippet that halts
in RELEASE builds, and in DEBUG builds
RH covscan justifiedly reports that accessing "EFI_FFS_FILE_HEADER.Size"
and "EFI_COMMON_SECTION_HEADER.Size", which both are of type UINT8[3],
through (UINT32*), is undefined behavior:
> Error: OVERRUN (CWE-119):
> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:283: overrun-local: Overrunning
> array
Accessing "EFI_FFS_FILE_HEADER.Size", which is of type UINT8[3], through a
(UINT32*), is undefined behavior. Fix it by accessing the array elements
individually.
(We can't use a union here, unfortunately, as easily as with
"EFI_COMMON_SECTION_HEADER", given the fields in "EFI_FFS_FILE_HEADER".)
RH covscan warns about assignments that it can determine are never
"consumed" later ("dead stores"). The idea behind the warning is
presumably that the programmer forgot to implement a dependent check
somewhere.
For each such warning that has been emitted for OvmfPkg,
the case is one of the
RH covscan justifiedly reports that accessing
"EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
(UINT32*), is undefined behavior:
> Error: OVERRUN (CWE-119):
> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
> array of 3 bytes at byte offset 3 by
RH covscan reports the following "nullptr deref" warning:
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5:
> warning: Dereference of null pointer
> #InstanceZero->NumInstancesUnion.NumInstances++;
> #^
>
The real mode interrupt vector table, which we modify for the sake of
Windows 7, starts at address 0, which happens to be the representation of
null pointers on all edk2 architectures. A null pointer may never undergo
pointer arithmetic, and RH covscan justifiedly reports:
> Error:
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Repo: https://github.com/lersek/edk2.git
Branch: covscan_bz_1710
"covscan" is an internal service at Red Hat that lets associates run
static analysis tools on Fedora/RHEL packages. It drives a number of
static analyzers.
While
On 04/13/19 00:50, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1656
>
> Change the Wiki documentation to state that the preferred license of the
> EDK II is the BSD+Patent License and remove references to the TianoCore
> Contributor's Agreement.
>
> Cc: Andrew Fish
I wasn't really thinking about efi code that can come in from device. I was
thinking more of a discrete device that you can solder down on the board and
manufacturer of such device can distribute a efi binary with it that will
contain only this small piece of code instead of the full blown
On 04/13/19 00:50, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1656
>
> With the change to BSD+Patent License, the TianoCore Contributor's
> Agreement has been removed and as a result, a Contributed under
> tag is no longer appropriate in commit messages. Remove this
Now that we have the edk2-test repo with the SCT infrastructure, has there been
any thought for where tests that use this for non-standardized protocols should
live? My initial thought is along with the protocols in edk2/edk2-platforms.
For example if you had
https://bugzilla.tianocore.org/show_bug.cgi?id=1656
* Change preferred license of EDK II to BSD+Patent
* Remove references to the TianoCore Contributor's Agreement
* Remove use of Contributed-under tags
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Signed-off-by: Michael D Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=1656
Change the Wiki documentation to state that the preferred license of the
EDK II is the BSD+Patent License and remove references to the TianoCore
Contributor's Agreement.
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Signed-off-by:
https://bugzilla.tianocore.org/show_bug.cgi?id=1656
With the change to BSD+Patent License, the TianoCore Contributor's
Agreement has been removed and as a result, a Contributed under
tag is no longer appropriate in commit messages. Remove this tag
from all commit message examples in the
On Fri, 12 Apr 2019 at 03:20, Marcin Wojtas wrote:
>
> In order to provide special handling for DT environment,
> implement custom version of DtLoaderLib, which registers
> ExitBootServices event upon generic 'DtAcpiPref' variable.
> The routine is responsible for disabling the PMU workaround,
>
On Fri, 12 Apr 2019 at 13:58, Kinney, Michael D
wrote:
>
> Ard,
>
> We have verified that the build failures are resolved.
>
> Series Reviewed-by: Michael D Kinney
>
Mike,
Thanks a lot for the effort in testing and reviewing.
I'll wait for the MdeModulePkg maintainers' feedback before
Ard,
We have verified that the build failures are resolved.
Series Reviewed-by: Michael D Kinney
Mike
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, April 11, 2019 1:58 PM
> To: edk2-devel-groups-io ; Ard
> Biesheuvel
> Cc: Zimmer,
The same issue is here:
https://lists.01.org/pipermail/edk2-devel/2018-February/021403.html
Is the ram disk API supported in the UEFI Interactive Shell v2.2 EDK II
UEFI v2.40?
I can successfully load RamDiskDxe.efi, however, where to go from there?
*Joe Teumer >*
Systems Verification Engineer
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf Of Felix Polyudov
> Sent: Friday, April 12, 2019 11:04 AM
> To: devel@edk2.groups.io; Schmauss, Erik
> ; ler...@redhat.com; Gao, Liming
>
> Cc: Moore, Robert
> Subject: Re: [edk2-devel] ASL
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Schmauss, Erik
> Sent: Thursday, April 11, 2019 7:10 PM
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> Yes, the current iASL preprocessor implementation is
Reviewed-by: Bob Feng
-Original Message-
From: Fan, ZhijuX
Sent: Wednesday, April 10, 2019 4:51 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C
Subject: [edk2][PATCH V2] BaseTools:Enable the /MP option of MSVC compiler
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1672
From: "Chasel, Chiu"
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1716
In API mode FSP wrapper will perform some post
FSP-S process but such process was skipped in Dispatch
mode which may impact some of boot loaders.
To align behavior between API and Dispatch, an
End-of-Pei callback is
UEFI_CapsuleOnDisk branch is used to develop the Capsule-On-Disk feature.
Please refer to the patch of Readme.md to get the detailed feature introduction.
Note: The branch will be created by the end of Apr 19th if no objection.
Cc: Kinney Michael D
mailto:michael.d.kin...@intel.com>>
Cc:
Hitherto SoC library of Armada7k8k was missing AP and CP-MSS
I2C controllers. Fix that and update Armada70x0Db and
Armada80x0Db I2C description accordingly.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
In order to provide special handling for DT environment,
implement custom version of DtLoaderLib, which registers
ExitBootServices event upon generic 'DtAcpiPref' variable.
The routine is responsible for disabling the PMU workaround,
that is valid only for UEFI and OS + APCI.
Contributed-under:
From: Grzegorz Jaszczyk
By mistake port0 of the second PP2 controller was configured
to 5G speed, instead of 10G. Fix it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc | 2 +-
1 file changed, 1
Hi,
After a longer time, I was able to put my hands on finalizing the upstream for
Armada7k8k platforms. In the meantime, when I polish the PCIE support,
please check 6 various small improvements / fixes for the support.
The patches are available in the github:
Extend MADT GICC table flags with PERFORMANCE_INTERRUPT_MODEL,
which is responsible for configuring interrupt type in the OS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc | 10 ++
1 file changed,
Due to the hardware issue, it is better to
use generic MdeModulePkg version of the watchdog
instead of the ArmPkg driver. It prevents unwanted
resetting of the platform when spending "too long"
inside the default boot manager.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by:
Hi,
Currently, we generally follow below process to handle security bugs.
But there're no document to describe the detailed working flow. There're
also discussions on lacking of important information, poor issue description
and no timely notification on update, etc.
"0 - New Security Bug"
On 04/11/19 21:59, Philippe Mathieu-Daudé wrote:
> On 4/11/19 9:53 PM, Rebecca Cran wrote:
>> On 2019-04-11 13:30, Rebecca Cran via Groups.Io wrote:
>>>
>>> I'm sending emails on Thunderbird via Postfix, so there's no Outlook
>>> involved.
>>>
>>
>> Let's try again: I've unset the groups.io
On 04/12/19 05:14, Gao, Zhichao wrote:
> For now most platforms support display function at PEI phase.
> But the conspliter and graphics console driver would clear the
> screen at BDS connect console phase. Maybe some platforms would
> show logo in the next or maybe not. For consumers, it looks
On 04/11/19 22:11, Philippe Mathieu-Daudé wrote:
> On 4/11/19 9:58 PM, Rebecca Cran wrote:
>> On 2019-04-11 13:55, Philippe Mathieu-Daudé wrote:
>>>
>>> With the work around link added:
>>> Reviewed-by: Philippe Mathieu-Daude
>>
>>
>>
>> But it's _not_ working around that bug. That was about
On 04/11/19 21:59, Philippe Mathieu-Daudé wrote:
> On 4/11/19 9:53 PM, Rebecca Cran wrote:
>> On 2019-04-11 13:30, Rebecca Cran via Groups.Io wrote:
>>>
>>> I'm sending emails on Thunderbird via Postfix, so there's no Outlook
>>> involved.
>>>
>>
>> Let's try again: I've unset the groups.io
Resend this one to the new mailing list.
Hello Mateusz,
Incline comments below.
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, April 11, 2019 9:39 AM
> To: Wu, Hao A; edk2-de...@lists.01.org
> Cc: Ni, Ray
> Subject: RE: [PATCH 3/3] MdeModulePkg/UfsPassThruDxe: Add UFS
41 matches
Mail list logo
