[edk2] LocateHandle for gEfiShellProtocolGuid is failing in my application

[GN Keshava]

Hi,

I'm developing a shell application. A call to LocateHandle for
gEfiShellProtocolGuid is failing with Status 0x0E.

Below is my code. Please let me know what I'm doing wrong.

Status = gBS->LocateHandle(ByProtocol, , NULL,
, Buffer); // Get BufferSize
if (EFI_ERROR(Status))
Print(L"LocateHandle Status 0x%x\n",Status);

Status = gBS->AllocatePool(EfiBootServicesData, BufferSize,
(void**));
if (EFI_ERROR(Status))
Print(L"AllocatePool Status 0x%x\n",Status);

Status = gBS->LocateHandle(ByProtocol, , NULL,
, Buffer);
if (EFI_ERROR(Status))
Print(L"LocateHandle Status 0x%x\n",Status);

All calls failing with Status being 0x0E. Please help me to solve this. Is
there any special requirement for using this protocol?

Thanks.
Regards,
Keshava
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v7] BaseTools/Scripts/PatchCheck.py: Extended patch style check for c code

[Jordan Justen]

On 2016-12-19 00:31:13, Gao, Liming wrote:
> Daniil:
>   This version has addressed my comments. I see Jordan also provides
>   some comments. Are they handled in this patch?
>

No, they were not addressed. Here are my replies:

v5: https://lists.01.org/pipermail/edk2-devel/2016-December/005779.html

v6: https://lists.01.org/pipermail/edk2-devel/2016-December/005866.html

>
> > -Original Message-
> > From: Daniil Egranov [mailto:daniil.egra...@arm.com]
> > Sent: Saturday, December 17, 2016 7:11 AM
> > To: edk2-devel@lists.01.org
> > Cc: leif.lindh...@linaro.org; Gao, Liming ; Daniil
> > Egranov 
> > Subject: [PATCH v7] BaseTools/Scripts/PatchCheck.py: Extended patch style
> > check for c code
> > 
> > Changed output format to make it more comapct.
> > Disabled colored output by default. For terminals which support ANSI
> > escape codes, colored output can be enabled with the "--color" command
> > line parameter.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Daniil Egranov 
> > ---
> > Changelog:
> > 
> > v6
> > Added reporting a source code line number in case of error when
> > checking a patch file or using a git sha1 commit string. In case of
> > a patch file, both patch and source code line numbers will be provided.
> > Corrected handling the case with #define foo(..) macro. The absence of
> > the space before open parenthesis is not reported as the error anymore.
> > Added checking for lower case "void" and "static" words.
> > Added colors for error messages (experimental?)
> > 
> > v5
> > Corrected code checking for multi-line and commented lines. Both
> > multi-line and open comment flags will be reset when leaving
> > diff "+" area of the patch.
> > Changed version of the tool to 0.2.
> > 
> > v4
> > Corrected maximum code line size to 120 characters.
> > 
> > v3
> > Corrected space detection before parentheses.
> > 
> > v2:
> > Fixed several indentation cases
> > 
> > v1:
> > Fixed reporting signature error for a cover letter.
> > Fixed reporting line size error for a file change information
> > included in the commit message.
> > Fixed line number reported in PatchCheck error messages. It
> > points to the correct line in the diff file.
> > The patch extends style checking for c code:
> >  Added check for code indentation.
> >  Added report line size greater than 80 characters.
> >  Added checking for space before '('.
> >  Added checking for space before '{'.
> >  Added checking for '}' to be on a new line and have spaces
> >  for "} else {" or "} while ()" cases.
> > 
> >  BaseTools/Scripts/PatchCheck.py | 379
> > 
> >  1 file changed, 341 insertions(+), 38 deletions(-)
> > 
> > diff --git a/BaseTools/Scripts/PatchCheck.py
> > b/BaseTools/Scripts/PatchCheck.py
> > index 7c30082..eae084c 100755
> > --- a/BaseTools/Scripts/PatchCheck.py
> > +++ b/BaseTools/Scripts/PatchCheck.py
> > @@ -15,7 +15,7 @@
> > 
> >  from __future__ import print_function
> > 
> > -VersionNumber = '0.1'
> > +VersionNumber = '0.2'
> >  __copyright__ = "Copyright (c) 2015 - 2016, Intel Corporation  All rights
> > reserved."
> > 
> >  import email
> > @@ -25,6 +25,44 @@ import re
> >  import subprocess
> >  import sys
> > 
> > +class MsgFormat:
> > +ERROR, WARNING, REPORT, LINK, NORMAL = range(5)
> > +color_on = False
> > +
> > +class ColorTypes:
> > +RED = '\033[91m'
> > +GREEN = '\033[92m'
> > +BLUE = '\033[94m'
> > +CYAN = '\033[96m'
> > +WHITE = '\033[97m'
> > +YELLOW = '\033[93m'
> > +MAGENTA = '\033[95m'
> > +GREY = '\033[90m'
> > +BLACK = '\033[90m'
> > +DEFAULT = '\033[0m'
> > +
> > +class TextColor:
> > +def __init__(self, color_on, msg_format):
> > +self.color = ''
> > +if color_on == True:
> > +if msg_format == MsgFormat.ERROR:
> > +self.color = ColorTypes.RED
> > +elif msg_format == MsgFormat.WARNING:
> > +self.color = ColorTypes.YELLOW
> > +elif msg_format == MsgFormat.REPORT:
> > +self.color = ColorTypes.CYAN
> > +elif msg_format == MsgFormat.LINK:
> > +self.color = ColorTypes.BLUE
> > +elif msg_format == MsgFormat.NORMAL:
> > +self.color = ColorTypes.DEFAULT
> > +else:
> > +self.color = ColorTypes.DEFAULT
> > +else:
> > +self.color = ''
> > +
> > +def __str__(self):
> > +return self.color
> > +
> >  class Verbose:
> >  SILENT, ONELINE, NORMAL = range(3)
> >  level = NORMAL
> > @@ -32,7 +70,7 @@ class Verbose:
> >  class CommitMessageCheck:
> >  """Checks the contents of a git commit message."""
> > 
> > -def __init__(self, subject, message):
> > +def __init__(self, subject, message, message_offset, cover):
> >  self.ok = True
> > 
> >  if subject is None and  

Re: [edk2] [patch 2/8] FatPkg\EnhancedFatDxe: Initialize variable after declaration

[Brian J. Johnson]

On 12/08/2016 05:11 PM, Andrew Fish wrote:

On Dec 8, 2016, at 9:27 AM, Kurt Kennett  wrote:

This seems kind of silly.
Why isn't this just const data?  This adds code and memory accesses that are 
worthless and happen on every call to the function.


K2,

I think this is an attempt to conform to the coding standard?


I just went looking through the C Coding Standards document 
(https://github.com/tianocore-docs/Docs/raw/master/Specifications/CCS_2_1_Draft.pdf) 
and couldn't actually find this requirement.  Which really surprises 
me... I must not be using the right search terms.


Could someone point out the specific section covering this requirement? 
I have somebody asking me about it internally here.


Sorry to be both dense and pedantic,
--

Brian J. Johnson



  My statements are my own, are not authorized by SGI, and do not
  necessarily represent SGI’s positions.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 1/2] UefiCpuPkg: Add Pcd info to uni file

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

> -Original Message-
> From: Bi, Dandan
> Sent: Monday, December 19, 2016 11:53 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Fan, Jeff
> 
> Subject: [patch 1/2] UefiCpuPkg: Add Pcd info to uni file
> 
> Add PcdCpuSmmStmExceptionStackSize/PcdCpuMsegSize prompt and help
> string to uni file
> 
> Cc: Michael Kinney 
> Cc: Jeff Fan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  UefiCpuPkg/UefiCpuPkg.uni | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
> index 298ed7e..f4dd339 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -153,5 +153,13 @@
> 
> "If enabled, SMM will not use on-demand paging. SMM will build static page 
> table
> for all memory.\n"
> 
> "This flag only impacts X64 build, because SMM alway builds static page table 
> for
> IA32.\n"
> 
> "TRUE  - SMM uses static page table for all memory.\n"
> 
> "FALSE - SMM uses static page table for below 4G memory and use on-demand 
> paging
> for above 4G memory."
> 
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmStmExceptionStackSize_PROMPT
> #language en-US "STM exception stack size."
> +
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmStmExceptionStackSize_HELP
> #language en-US "Specifies buffer size in bytes for STM exception stack. The
> value should be a multiple of 4KB."
> +
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuMsegSize_PROMPT  #language en-US
> "MSEG size."
> +
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuMsegSize_HELP  #language en-US
> "Specifies buffer size in bytes of MSEG. The value should be a multiple of 
> 4KB."
> +
> --
> 1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

[Yao, Jiewen]

Thank you, Lloyd.

Comment inline.

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Evan 
Lloyd
Sent: Tuesday, December 20, 2016 9:21 PM
To: Yao, Jiewen ; Ni, Ruiyu ; Carsey, 
Jaben ; Sami Mujawar 
Cc: Carsey, Jaben ; edk2-de...@ml01.01.org; Leif 
Lindholm ; ard.biesheu...@linaro.org
Subject: Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

Hi Jiewen.
Some responses inline below:

> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: 20 December 2016 05:54
> To: Ni, Ruiyu; Carsey, Jaben; Evan Lloyd
> Cc: Carsey, Jaben; edk2-de...@ml01.01.org; 
> Leif Lindholm; ard.biesheu...@linaro.org
> Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables
>
> I like this idea - Shell.efi should only support commands defined by Shell 
> spec.
> Then we should not port code to be a shell library.
>
> I have concern on ShellPkg\Library\UefiDpLib, because DP depends on TimerLib 
> and TimerLib is a platform specific library.
> I do not object the idea to move DP from performancepkg to shellPkg.
> I would suggest DP had better be a standard shell application, rather than a 
> shell lib and included in a shell bin.
>
>
> Now back to acpiview:
> First, it is great to have such tool in UEFI shell.

Thanks.  We hoped people would see the benefit.

>
> Second, I found the function is incomplete.
> 1)   Some ACPI defined tables are not complete. Take MADT as example, it 
> only supports 
> EFI_ACPI_6_1_GIC/EFI_ACPI_6_1_GICD/EFI_ACPI_6_1_GIC_MSI_FRAME/EFI_ACPI_6_1_GICR/EFI_ACPI_6_1_GIC_ITS.
> 2)   Some ACPI defined tables are missing. Such as BGRT, FPDT.

At this stage we have only added tables for which we had an immediate use, as 
available effort is limited.
In addition, we did not want to submit code we were not able to test.  Clearly, 
our platforms use GIC, not APIC.
Also  we are not well placed to judge the best representation for some fields, 
e.g. are APIC interrupt numbers normally decimal or hex?

[Jiewen] Got it.
As you mention, I hope it can be in SHELL spec, too.

So that we can have a standard way to dump all table information.

For X86 system, I have written similar tool to dump X86 related info.
I just check in to 
https://github.com/jyao1/EdkiiShellTool/tree/master/AcpiToolPkg.
It is also BSD license code. I tried by best to dump info for *all* the ACPI 
table.
But I do not validate ARM system. We complement to each other. :)

And mine does not have any consistency *check* function so far.
Your #2 below is very good.


> 3)   I found some ACPI reserved tables are added here. Such as DBG2, IORT.

Is there any problem with dumping the reserved tables?
[Jiewen] No problem at all.
This question is combined with 4). And I hope it can be complete as well.

> 4)   But not all ACPI reserved tables are added. Such as HPET, TPM2.

We only wrote code for tables we could test.  We have no example 
hardware/firmware with those tables.
[Jiewen] Same as 2). I have written tool for X64 system, but not for ARM.

> May I know what criteria we are using to select which feature is supported or 
> not supported?

As stated above, we only provided the tables/sections that we needed to dump 
and could test.
>From the commit message:
"""
Many tables are not explicitly handled, in part because no examples are 
available for our testing.

The program is designed to be extended to new tables with minimal effort, and 
contributions are invited.
"""
[Jiewen] Got it and agree.

> Or it is just something from start and still need some work to make it 
> complete?

Yes, this is just a starting point and very far from complete.
We found it detected a number of problems for us, so we felt it worth 
contributing.
If we can get people to use it, that may mean fewer problems for us to debug.   
;-)
[Jiewen] See my last comment.

>
> Third, I found we need a long ? ?switch (*AcpiTableSignature) case? to 
> dump/parse ACPI table specific function.
> Do you think it will be better, that we provide a register function to let 
> each ACPI table register a parser?
> For example: RegisterDumpAcpiTable (EFI_ACPI_1_0_APIC_SIGNATURE, 
> DumpAcpiMADT);
> Then the core logic just need use a table-driven way to find out the 
> corresponding parser function by a SIGNATURE.

You are right, that would be a much better abstract design, and would make 
adding a table simpler.
We discussed this in our pre-release review.
The trade-off is that you need to maintain a dynamic registry of handlers, and 
write your own lookup code.
Using a switch eliminates the registry, and relies on the compiler for 
efficient look up.
We would be very happy with this change, should someone have the time available 
to contribute it.
[Jiewen] Thank you considering that. Actually, I have such code for X86 

Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

[Evan Lloyd]

Hi Jiewen.
Some responses inline below:

> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: 20 December 2016 05:54
> To: Ni, Ruiyu; Carsey, Jaben; Evan Lloyd
> Cc: Carsey, Jaben; edk2-de...@ml01.01.org; Leif Lindholm; 
> ard.biesheu...@linaro.org
> Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables
>
> I like this idea - Shell.efi should only support commands defined by Shell 
> spec.
> Then we should not port code to be a shell library.
>
> I have concern on ShellPkg\Library\UefiDpLib, because DP depends on TimerLib 
> and TimerLib is a platform specific library.
> I do not object the idea to move DP from performancepkg to shellPkg.
> I would suggest DP had better be a standard shell application, rather than a 
> shell lib and included in a shell bin.
>
>
> Now back to acpiview:
> First, it is great to have such tool in UEFI shell.

Thanks.  We hoped people would see the benefit.

>
> Second, I found the function is incomplete.
> 1)   Some ACPI defined tables are not complete. Take MADT as example, it 
> only supports 
> EFI_ACPI_6_1_GIC/EFI_ACPI_6_1_GICD/EFI_ACPI_6_1_GIC_MSI_FRAME/EFI_ACPI_6_1_GICR/EFI_ACPI_6_1_GIC_ITS.
> 2)   Some ACPI defined tables are missing. Such as BGRT, FPDT.

At this stage we have only added tables for which we had an immediate use, as 
available effort is limited.
In addition, we did not want to submit code we were not able to test.  Clearly, 
our platforms use GIC, not APIC.
Also  we are not well placed to judge the best representation for some fields, 
e.g. are APIC interrupt numbers normally decimal or hex?

> 3)   I found some ACPI reserved tables are added here. Such as DBG2, IORT.

Is there any problem with dumping the reserved tables?

> 4)   But not all ACPI reserved tables are added. Such as HPET, TPM2.

We only wrote code for tables we could test.  We have no example 
hardware/firmware with those tables.

> May I know what criteria we are using to select which feature is supported or 
> not supported?

As stated above, we only provided the tables/sections that we needed to dump 
and could test.
>From the commit message:
"""
Many tables are not explicitly handled, in part because no examples are 
available for our testing.

The program is designed to be extended to new tables with minimal effort, and 
contributions are invited.
"""

> Or it is just something from start and still need some work to make it 
> complete?

Yes, this is just a starting point and very far from complete.
We found it detected a number of problems for us, so we felt it worth 
contributing.
If we can get people to use it, that may mean fewer problems for us to debug.   
;-)

>
> Third, I found we need a long ? ?switch (*AcpiTableSignature) case? to 
> dump/parse ACPI table specific function.
> Do you think it will be better, that we provide a register function to let 
> each ACPI table register a parser?
> For example: RegisterDumpAcpiTable (EFI_ACPI_1_0_APIC_SIGNATURE, 
> DumpAcpiMADT);
> Then the core logic just need use a table-driven way to find out the 
> corresponding parser function by a SIGNATURE.

You are right, that would be a much better abstract design, and would make 
adding a table simpler.
We discussed this in our pre-release review.
The trade-off is that you need to maintain a dynamic registry of handlers, and 
write your own lookup code.
Using a switch eliminates the registry, and relies on the compiler for 
efficient look up.
We would be very happy with this change, should someone have the time available 
to contribute it.

Our review also suggested changing the switch to just set a function pointer, 
with a single call at the end.
That would make each switch case much simpler.  Would that be an acceptable 
"half-way house"?

>
> Finally, I agree with Ruiyu that a standalone tool might be more proper.

Agreed in other response.

>
> Thank you
> Yao Jiewen

>> > > ...
> > > >> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

[Evan Lloyd]

Hi Ray.
Comments inline below

>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: 20 December 2016 02:59
>To: Carsey, Jaben; Evan Lloyd
>Cc: Leif Lindholm; ard.biesheu...@linaro.org; edk2-de...@ml01.01.org
>Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI
>tables
>
>Evan,
>Thanks for the answers. BSD license of your code is great! Thanks for your
>contribution.
>But I do have some other thoughts in below.
>
>Jaben, Evan,
>The implementation style of "acpiview" is to embed it into "Shell.efi" as an
>internal
>command, in "Debug1" profile.
>
>I am afraid it's a violation of Shell spec because Shell spec defines a fixed 
>list
>of commands
>that belongs to "Debug1" profile, while "acpiview" isn't in the list.

Don't tell anyone, but we hope eventually to get this added to the shell spec.
We wrote the tool to investigate some problems, and it proved so useful that we 
wanted to make it available as quickly as possible.

>On the other side, some people may want a standalone "acpiview.efi" that
>he use it in
>any UEFI Shell environment.

Sami originally had this - I am to blame for making it a Shell app like 
smbiosview.

The .efi is helpful for platforms that support USB drives, as you can just 
invoke it off a drive.
Sami will look at adding the INF #2 to our patch.

>
>How about we provide two INF files for this tool:
>1. NULL class INF providing constructor/destructor(Current INF)
>2. APP INF generating standalone "acpiview.efi" (New INF I want)
>
>When creating INF #2, in order to embed the help message into the
>resource section of EFI file
>so that Shell core can find it and display when "-?" is typed, we need to:
>1. declare "UEFI_HII_RESOURCE_SECTION  = TRUE" to let build tool embed
>HII resource (string)
>into the resource section.
>2. write code in entrypoint of application to retrieve the string resource
>from ImageHandle, and
>free the resource in Unload.
>Sample code is in
>MdeModulePkg/Universal/HiiResourcesSampleDxe/HiiResourcesSample.c
>3. Explicitly reference the token ID of help string in C file so that build 
>tool
>doesn't optimize out
>the help string from HII resource.
>Sample code in MdeModulePkg/Application/HelloWorld/HelloWorld.c:
>GLOBAL_REMOVE_IF_UNREFERENCED EFI_STRING_ID
>mStringHelpTokenId
> = STRING_TOKEN
>(STR_HELLO_WORLD_HELP_INFORMATION);
>
>The step 2&3 can be put in a new .C file that only be referenced by the APP
>INF file.

Thank you for the pointers.  We'll add this advice into our next update.

>
>Since now we provide both library and application for acpiview, how about
>put it in new location
>ShellPkg/Application/AcpiView directory?

You're the maintainer - we'll happily take your advice on the best place for it.

>
>What's your option? If you agree, I can help to create the APP INF.

We'll take all the help we can get, please.  If you would like to send us a 
.INF, we'd be grateful for the time it will save us.

>
>Thanks/Ray
>
>> -Original Message-
>> From: Carsey, Jaben
>> Sent: Tuesday, December 20, 2016 2:01 AM
>> To: Evan Lloyd ; Ni, Ruiyu ;
>> edk2-de...@ml01.01.org
>> Cc: Leif Lindholm ; ard.biesheu...@linaro.org;
>> Carsey, Jaben 
>> Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI
>tables
>>
>> I am good with this addition.  The BSD is a huge advantage for me.
>>
>> Reviewed-by: Jaben Carsey 
>>
>> I will allow Ray to resolve any issues he and push it.
>>
>> -Jaben
>>
>> > -Original Message-
>> > From: Evan Lloyd [mailto:evan.ll...@arm.com]
>> > Sent: Monday, December 19, 2016 7:57 AM
>> > To: Ni, Ruiyu ; edk2-de...@ml01.01.org
>> > Cc: Carsey, Jaben ; Leif Lindholm
>> > ; ard.biesheu...@linaro.org
>> > Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI
>> > tables
>> > Importance: High
>> >
>> > Hi Ray.
>> > Good question.  Answer inline.
>> >
>> > >-Original Message-
>> > >From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>> > >Sent: 19 December 2016 09:49
>> > >To: Evan Lloyd; edk2-de...@ml01.01.org
>> > >Cc: Carsey, Jaben; Leif Lindholm; ard.biesheu...@linaro.org
>> > >Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI
>> > >tables
>> > >
>> > >I happened to find another version of acpi dump tool in shell.
>> > >Binary can be downloaded from: https://acpica.org/downloads/uefi-
>> > >support
>> > >Source can be downloaded from: https://github.com/acpica/acpica
>> > >
>> > >Are there any differences between the above one and yours?
>> >
>> > The main differences are:
>> > 1.acpiview provides a formatted dump of non-AML tables at the Shell
>level.
>> > This provides the  equivalent of using acpidump -b, then transferring
>> > the file to use "iasl -d" on another system.  However, it works 

Re: [edk2] [PATCH 0/6] Refine code logics to prevent possible mis-reports by static code checkers

[Wu, Hao A]

Hi Heyi,

For the warnings reported by the static checkers you mentioned, could you
help to analyze those issues and find out if there are real issues exist?

If there are real code issues, I think you can report them to Bugzilla
with the appropriate classification (e.g. Security or Not Security
Related).

Thanks in advance.

Best Regards,
Hao Wu

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
> Guo
> Sent: Sunday, December 18, 2016 11:04 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Ye, Ting; Gao, Liming; Wu, Jiaxin; Yao, Jiewen; Kinney, Michael D; Fu, 
> Siyuan
> Subject: Re: [edk2] [PATCH 0/6] Refine code logics to prevent possible mis-
> reports by static code checkers
> 
> Hi Hao,
> 
> May I ask which static code checkers you are using?
> 
> We are using Coverity and Fortify checkers, and there are hundreds of
> warnings reported. Do you have a plan to analyze and fix (some may be
> not real errors) the warnings from these two checkers?
> 
> Thanks and regards,
> 
> Heyi
> 
> 在 12/14/2016 7:26 PM, Hao Wu 写道:
> > The series refines the loop logic (e.g. for, while) of some functions to
> > be more straightforward. This will help to prevent some possible
> > mis-reports by static code checkers
> >
> > Cc: Jiewen Yao 
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Fu Siyuan 
> > Cc: Ye Ting 
> > Cc: Wu Jiaxin 
> >
> > Hao Wu (6):
> >MdePkg/BaseLib: Refine (Ascii)StrnLenS functions logic
> >MdePkg/BaseLib: Add an additional check within (Ascii)StrnCmp
> >MdePkg/MemoryLib: Refine InternalMemSetMem16|32|64 functions logic
> >MdeModulePkg/DxeNetLib: Rewrite NetblockChecksum function logic
> >MdeModulePkg/UefiPxeBcDxe: Refine the CvtNum function logic
> >NetworkPkg: Refine UintnToAscDecWithFormat functions logic
> >
> >   MdeModulePkg/Library/DxeNetLib/NetBuffer.c | 16 
> > 
> >   .../Universal/Network/UefiPxeBcDxe/PxeBcSupport.c  |  5 ++---
> >   MdePkg/Library/BaseLib/SafeString.c| 16 
> > 
> >   MdePkg/Library/BaseLib/String.c|  4 +++-
> >   MdePkg/Library/BaseMemoryLib/MemLibGeneric.c   | 18 +--
> ---
> >   MdePkg/Library/PeiMemoryLib/MemLibGeneric.c| 18 +
> -
> >   MdePkg/Library/UefiMemoryLib/MemLibGeneric.c   | 18 +---
> --
> >   NetworkPkg/HttpBootDxe/HttpBootSupport.c   |  5 ++---
> >   NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c |  5 ++---
> >   9 files changed, 56 insertions(+), 49 deletions(-)
> >
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SecurityPkg Tcg2ConfigDxe: Force reset when PCR Allocation changed.

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Dong, Eric 
Sent: Tuesday, December 20, 2016 3:57 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star 
Subject: [Patch] SecurityPkg Tcg2ConfigDxe: Force reset when PCR Allocation 
changed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
---
 SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr 
b/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
index 48e9943..57f37be 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
@@ -154,7 +154,7 @@ formset
 questionid = KEY_TPM2_PCR_BANKS_REQUEST_0,
 prompt = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA1),
 help   = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA1_HELP),
-flags  = INTERACTIVE,
+flags  = INTERACTIVE | RESET_REQUIRED,
 default= 1,
 endcheckbox;
   endif;
@@ -164,7 +164,7 @@ formset
 questionid = KEY_TPM2_PCR_BANKS_REQUEST_1,
 prompt = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA256),
 help   = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA256_HELP),
-flags  = INTERACTIVE,
+flags  = INTERACTIVE | RESET_REQUIRED,
 default= 0,
 endcheckbox;
   endif;
@@ -174,7 +174,7 @@ formset
 questionid = KEY_TPM2_PCR_BANKS_REQUEST_2,
 prompt = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA384),
 help   = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA384_HELP),
-flags  = INTERACTIVE,
+flags  = INTERACTIVE | RESET_REQUIRED,
 default= 0,
 endcheckbox;
   endif;
@@ -184,7 +184,7 @@ formset
 questionid = KEY_TPM2_PCR_BANKS_REQUEST_3,
 prompt = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA512),
 help   = STRING_TOKEN(STR_TCG2_PCR_BANK_SHA512_HELP),
-flags  = INTERACTIVE,
+flags  = INTERACTIVE | RESET_REQUIRED,
 default= 0,
 endcheckbox;
   endif;
@@ -194,7 +194,7 @@ formset
 questionid = KEY_TPM2_PCR_BANKS_REQUEST_4,
 prompt = STRING_TOKEN(STR_TCG2_PCR_BANK_SM3_256),
 help   = STRING_TOKEN(STR_TCG2_PCR_BANK_SM3_256_HELP),
-flags  = INTERACTIVE,
+flags  = INTERACTIVE | RESET_REQUIRED,
 default= 0,
 endcheckbox;
   endif;
-- 
2.6.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel