date:20171016

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Logo

2017-10-16 Thread Wei, David

Reviewed-by: zwei4  

Thanks,
David  Wei

Intel SSG/STO/UEFI BIOS 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> xianhu2x
> Sent: Tuesday, October 17, 2017 10:59 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017]
> Logo
> Importance: High
> 
> Change QR code from https://minnowboard.org to
> https://minnowboard.org/setup
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: xianhu2x 
> ---
>  .../Board/MinnowBoard3/Logo/MinnowBoardLogo.bmp | Bin 54670 ->
> 29754 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git
> a/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/Logo/MinnowBoard
> Logo.bmp
> b/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/Logo/MinnowBoard
> Logo.bmp
> index
> 7d7796e18777e34b802728bfe8ac7815da05256e..073b4cb7149a8fa76f49d7cd6
> 55dbca865d88892 100644
> GIT binary patch
> literal 29754
> zcmeIwL5gkF5`@i
> %tFa
> zf4}_p-It%A=kHJR`|JOIzyI#XFZmDC|NfuX@0Vcy{PFzkzQFUXcHikQ>-kpCx7vS!
> zz4`oKJ>P2o1@`9ifAxH;{TJAq&;Ql)t@dAFZ$AH5&$rrtfxWr>zZ{CLklS@O5D
> zHUpX@fdkUXWaJDpvGWcryc;i5HUqLGfdkUXWaJDpvGWcryc;i5HUqLGfdkU
> XWaJDp
> zIofGFr%Iwq$c5=h$e>i54a}aU_PV%{Ir+$vs1kBvIubG{6=wspXQ{m|Ze
> d6
> zT$ql83`)h>!0cISuZv_4NJvMLU_7f#$l%DysZ4UAWMo_*cS;iMQArXujwv!w0T
> sxq
> zB|-
> U6t_m2>L zB&1Uk6(|eSk$@b}gnR_EXX86ZmL#N85)~*5(~*E2{BPn1H
> M*>R4
> zDPa5#X7gsy1IUtubR-
> 4r;YdKKI0cN~!ED|PdH`9HkdCB)Jsb%r6{mplJDAOzK@Zr-
> zoHC^XrZ%vd;v{TNq%(Um%*45@N>Zj(NGsQ{Bg_~sdEVb9gjm+^#2~Y
> vm1~yZi
> zgw2U`W>1EhgXqo-
> lhd%*44n
> zu+X@q0J(s1P9{f{@r2ov;pY<125w0bIDjKb;DF*}mC5YM@N oag
> z%4GIr__@Thfm@OU4= Kn4
> zFqM^ra|iYu!Q9`6N@SOjLkVU?X$xpj zIIbk5BT2~dO=3@x(~$t z7%yNCAa4?K!i;B_NnS}O6H|aANhpr0z-
> FOwvZTPsrBxm6%&8ogBy7ex37dtc$dUph
> zm-enYeZb3i%Q#Raa1zLyidWPV5=?C>a)H@X+PlizHsdKvK-
> t4d
> zFtw@31!hlaRpnf9Or;|!kmF=k0taw1$%>OOa)z1M2{um3ndBZxkyQ!C0Vk8JI0
> ++X
> zn2DWW Yb2XG{x
> zgSmCLygc%*@(kk%9Kex$4(8To`O%ZeAWx_OCll2Xlszi2**x-
> 6d#yc^%S%+i=1f#a
> zQ1+<6X7k8P?X~tuE-
> z65n=?@zLD{1Mo6RF{v~*laNLfNYO31*T1kMJGFXfGvjw=Z%
> zOUOqF8Q7D+*?{q-ywTEeB_U-A`6wX+dlEPsFus(Rnzb)5C6@pdPyrRlDw86sz-
> F9N
> zU>25EgaZZ6*SX!04AS($V0~Jt#tTHLG3T(zX1!iGs|Mk
> lI
> zffEv-
> `bJ zTGi3rlylGLlDxi2yr;nIDXnUAt~j~pb4htdsl2DajF(pBiev*hB>}ld1vnCrm1G0C
> zr%a7pTGi3cGGz}S0~I)`$Q#HLWoqQos*ZM+DSH4JsK8N0-
> awuxQzMsFl{+N~n<);k
> zClggd%9$KZ8Bdr!8D`>~N|KOHNlKNQGr1ctQ>uiyo?#{)sgfk5Q<75U=1lI!%akf%
> zu4kBuN2(+V=}16MWm04nFrJADq$4RX )uRh26$
> zP^Pjnl~80AFrJADq$4RX qt$X
> zl~uP^MG~GoE24<%$XzFNvyvJqe~%B~gJgrAnCb3^U0q>12{qnV8CIlaz5)fj
> rUW
> z(yESjmZ`EQt4|*qyw6jc=Jy~s%a!XYpPjtDoDm(AM9*}#ok^oZ@pt
> =Kl
> z3e4uxs_q_O${wHsSxG?3S#gfQo@KDcb{zqauS%#W?~e3e3XNKG
> pjdc)r#9
> z*XaCwtNwl7+vi)oe~r%1x9Z>Ly?wsb``76Fe5?L_-rMI}y?>3)&$sH|=e>Qt)%(}z
> U{Cunaecs#WTfKjc`3)`b
> 
> literal 54670
> zcmeI4Ka%H25rstr1{P >w!
> zs(XeA?bgh^Exr8nGApxs*4T*s)1UwPui^REAAdUxf6&)|0>2r4_iX>mKZoJ(zd!
> J7
> zc=^XN4Ei%H%W>$R`W&`x8@7LM!_WWt+c1oiFbi^wtFQ_CFie9m3i_C4VG&
> kg6ZT=4
> z2VoQ@L1bQpRoH|*>W(@mVHOr)6*gfX27M0eC``gEEW#>m!mcI YR@HenwI
> z{TcRAn1oqagjLvteV7KdIgG;7?^#%cRoI06xY{`CoP=3egjLvt{kZlt>YRjGScFyB
> zg#8%FJnEc;Sy+Ts*o6HU*D~sygjraGRoI06809+ZoP=3egjLvt{TTB$>YRjGScFyB
> zg#CF1(?05)gjraGRoH}mSakno7=@>s&%)F1RoH}mSjIsZg-
> Mu*pIbMqs~c~
> zg+*9}P1ui>}Hg-zIxb*sp-
> Ou{TI!YXXSemsSB)Hw;Wun4QL3H$L(wo
> z%)%n9!Y1s`PiWakos%#Ni?9ltun(K=zYU`>3A3;WtMK%DKc3b&>YRjGScFyBg#
> CDS
> z)2MS2W?>OlVH5V_NzS9rNtlI2ScOg4kLS9KIwxTk7GV`OVLzVoI_jK+Sy+Ts*o6
> If
> z=G&-q5@ul$*5T*>ej9#L+# Z%7{Ob4oW$n4|v+whc6X@^u
> zj$3=+1%07_j$*yJ?^>h^YLu%=;`~s Hh1*|vk9+R>d_0>w
> zdip-
>

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] TPM Device

2017-10-16 Thread Wei, David

Reviewed-by: zwei4 

Thanks,
David  Wei

Intel SSG/STO/UEFI BIOS 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> xianhu2x
> Sent: Tuesday, October 17, 2017 11:00 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017]
> TPM Device
> Importance: High
> 
> "TPM Device" setup display redundant items. Remove "TPM Device" "dTPM
> 1.2" and "dTPM 2.0" options
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: xianhu2x 
> ---
>  .../Common/PlatformSettings/PlatformSetupDxe/Security.vfi   | 2 
> --
>  1 file changed, 2 deletions(-)
> 
> diff --git
> a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupD
> xe/Security.vfi
> b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetup
> Dxe/Security.vfi
> index 2d6b30873..d338a45c0 100644
> ---
> a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupD
> xe/Security.vfi
> +++
> b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetup
> Dxe/Security.vfi
> @@ -117,8 +117,6 @@ form formid = SECURITY_CONFIGURATION_FORM_ID,
>  help= STRING_TOKEN(STR_TPM_HELP),
>  option text = STRING_TOKEN(STR_DISABLE), value = 0x00, flags = DEFAULT
> | MANUFACTURING | RESET_REQUIRED;
>  option text = STRING_TOKEN(STR_TPM_PTT), value = 0x01, flags =
> RESET_REQUIRED;
> -option text = STRING_TOKEN(STR_TPM_DTPM_1_2), value = 0x02, flags =
> RESET_REQUIRED;
> -option text = STRING_TOKEN(STR_TPM_DTPM_2_0), value = 0x03, flags =
> RESET_REQUIRED;
>endoneof;
> 
>suppressif NOT ideqval Setup.TPM == 1;
> --
> 2.14.1.windows.1
> 
> ___
> 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][edk2-platforms/devel-MinnowBoard3-UDK2017] Boot Order

2017-10-16 Thread Wei, David

Reviewed-by: zwei4  

Thanks,
David  Wei

Intel SSG/STO/UEFI BIOS 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> xianhu2x
> Sent: Tuesday, October 17, 2017 10:59 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017]
> Boot Order
> Importance: High
> 
> Add "Commit Changes and Exit" option on "Change Boot Order" setup page.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: xianhu2x 
> ---
> 
> Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePag
> e.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePa
> ge.c
> b/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePa
> ge.c
> index bdf26141d..f3bd35ce9 100644
> ---
> a/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePa
> ge.c
> +++
> b/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePa
> ge.c
> @@ -548,7 +548,7 @@ UpdateOrderPage (
>EFI_QUESTION_ID   QuestionId;
>UINT16VarOffset;
> 
> -
> +  CallbackData->BmmAskSaveOrNot = TRUE;
>UpdatePageStart (CallbackData);
> 
>CreateMenuStringToken (CallbackData, CallbackData->BmmHiiHandle,
> OptionMenu);
> --
> 2.14.1.windows.1
> 
> ___
> 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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] TPM Device

2017-10-16 Thread xianhu2x

"TPM Device" setup display redundant items. Remove "TPM Device" "dTPM 1.2" and 
"dTPM 2.0" options

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: xianhu2x 
---
 .../Common/PlatformSettings/PlatformSetupDxe/Security.vfi   | 2 --
 1 file changed, 2 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/Security.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/Security.vfi
index 2d6b30873..d338a45c0 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/Security.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/Security.vfi
@@ -117,8 +117,6 @@ form formid = SECURITY_CONFIGURATION_FORM_ID,
 help= STRING_TOKEN(STR_TPM_HELP),
 option text = STRING_TOKEN(STR_DISABLE), value = 0x00, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
 option text = STRING_TOKEN(STR_TPM_PTT), value = 0x01, flags = 
RESET_REQUIRED;
-option text = STRING_TOKEN(STR_TPM_DTPM_1_2), value = 0x02, flags = 
RESET_REQUIRED;
-option text = STRING_TOKEN(STR_TPM_DTPM_2_0), value = 0x03, flags = 
RESET_REQUIRED;
   endoneof;
 
   suppressif NOT ideqval Setup.TPM == 1;
-- 
2.14.1.windows.1

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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Logo

2017-10-16 Thread xianhu2x

Change QR code from https://minnowboard.org to https://minnowboard.org/setup

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: xianhu2x 
---
 .../Board/MinnowBoard3/Logo/MinnowBoardLogo.bmp | Bin 54670 -> 29754 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/Logo/MinnowBoardLogo.bmp 
b/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/Logo/MinnowBoardLogo.bmp
index 
7d7796e18777e34b802728bfe8ac7815da05256e..073b4cb7149a8fa76f49d7cd655dbca865d88892
 100644
GIT binary patch
literal 29754
zcmeIwL5gkF5`@i%tFa
zf4}_p-It%A=kHJR`|JOIzyI#XFZmDC|NfuX@0Vcy{PFzkzQFUXcHikQ>-kpCx7vS!
zz4`oKJ>P2o1@`9ifAxH;{TJAq&;Ql)t@dAFZ$AH5&$rrtfxWr>zZ{CLklS@O5D
zHUpX@fdkUXWaJDpvGWcryc;i5HUqLGfdkUXWaJDpvGWcryc;i5HUqLGfdkUXWaJDp
zIofGFr%Iwq$c5=h$e>i54a}aU_PV%{Ir+$vs1kBvIubG{6=wspXQ{m|Ze
zT$ql83`)h>!0cISuZv_4NJvMLU_7f#$l%DysZ4UAWMo_*cS;iMQArXujwv!w0Tsxq
zB|-U6t_m2>LR4
zDPa5#X7gsy1IUtubR-4r;YdKKI0cN~!ED|PdH`9HkdCB)Jsb%r6{mplJDAOzK@Zr-
zoHC^XrZ%vd;v{TNq%(Um%*45@N>Zj(NGsQ{Bg_~sdEVb9gjm+^#2~Yvm1~yZi
zgw2U`W>1EhgXqo-lhd%*44n
zu+X@q0J(s1P9{f{@r2ov;pY<125w0bIDjKb;DF*}mC5YM@NWPV5=?C>a)H@X+PlizHsdKvK-t4d
zFtw@31!hlaRpnf9Or;|!kmF=k0taw1$%>OOa)z1M2{um3ndBZxkyQ!C0Vk8JI0++X
zn2DWW25EgaZZ6*SX!04AS($V0~Jt#tTHLG3T(zX1!iGs|MklI
zffEv-`bJ}ld1vnCrm1G0C
zr%a7pTGi3cGGz}S0~I)`$Q#HLWoqQos*ZM+DSH4JsK8N0-awuxQzMsFl{+N~n<);k
zClggd%9$KZ8Bdr!8D`>~N|KOHNlKNQGr1ctQ>uiyo?#{)sgfk5Q<75U=1lI!%akf%
zu4kBuN2(+V=}16MWm04nFrJADq$4RX12{qnV8CIlaz5)fjrUW
z(yESjmZ`EQt4|*qyw6jc=Jy~s%a!XYpPjtDoDm(AM9*}#ok^oZ@pt=Kl
z3e4uxs_q_O${wHsSxG?3S#gfQo@KDcb{zqauS%#W?~e3e3XNKGpjdc)r#9
z*XaCwtNwl7+vi)oe~r%1x9Z>Ly?wsb``76Fe5?L_-rMI}y?>3)&$sH|=e>Qt)%(}z
U{Cunaecs#WTfKjc`3)`b

literal 54670
zcmeI4Ka%H25rstr1{Pw!
zs(XeA?bgh^Exr8nGApxs*4T*s)1UwPui^REAAdUxf6&)|0>2r4_iX>mKZoJ(zd!J7
zc=^XN4Ei%H%W>$R`W&`x8@7LM!_WWt+c1oiFbi^wtFQ_CFie9m3i_C4VG=4
z2VoQ@L1bQpRoH|*>W(@mVHOr)6*gfX27M0eC``gEEW#>m!mcIYRjGScFyB
zg#8%FJnEc;Sy+Ts*o6HU*D~sygjraGRoI06809+ZoP=3egjLvt{TTB$>YRjGScFyB
zg#CF1(?05)gjraGRoH}mSakno7=@>s&%)F1RoH}mSjIsZg-Mu*pIbMqs~c~
zg+*9}P1ui>}Hg-zIxb*sp-Ou{TI!YXXSemsSB)Hw;Wun4QL3H$L(wo
z%)%n9!Y1s`PiWakos%#Ni?9ltun(K=zYU`>3A3;WtMK%DKc3b&>YRjGScFyBg#CDS
z)2MS2W?>OlVH5V_NzS9rNtlI2ScOg4kLS9KIwxTk7GV`OVLzVoI_jK+Sy+Ts*o6If
z=G&-q5@ul$*5T*>ej9#L+#h^YLu%=;`~sd_0>w

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Boot Order

2017-10-16 Thread xianhu2x

Add "Commit Changes and Exit" option on "Change Boot Order" setup page.

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: xianhu2x 
---
 Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c 
b/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
index bdf26141d..f3bd35ce9 100644
--- a/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
+++ b/Core/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
@@ -548,7 +548,7 @@ UpdateOrderPage (
   EFI_QUESTION_ID   QuestionId;
   UINT16VarOffset;
 
-
+  CallbackData->BmmAskSaveOrNot = TRUE;
   UpdatePageStart (CallbackData);
 
   CreateMenuStringToken (CallbackData, CallbackData->BmmHiiHandle, OptionMenu);
-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH] SecurityPkg:AuthVariableLib:Fix GCC build error

2017-10-16 Thread Gary Lin

On Mon, Oct 16, 2017 at 10:08:29PM +0800, Zhang, Chao B wrote:
> Fix GCC build error
> 
> Cc: Long Qin 
> Cc: Gary Lin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
> b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> index 7188ff6..1e7872a 100644
> --- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
> +++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> @@ -1564,7 +1564,7 @@ CalculatePrivAuthVarSignChainSHA256Digest(
>//
>// Get SignerCert CommonName
>//
> -  Status = X509GetCommonName(SignerCert, SignerCertSize, CertCommonName, 
> );
> +  Status = X509GetCommonName(SignerCert, SignerCertSize, (CHAR8 
> *)CertCommonName, );
Hi Chao Zhang,

Although casting also silences the warning, why not declare
CertCommonName as CHAR8 directly? The only signedness check happens
in X509GetCommonName(). Sha256Update() requests "VOID *" so the
signedness doesn't matter. Besides, AsciiStrLen() also requests
CHAR8, so declaring CertCommonName as CHAR8 can remove the casting
altogether. What do you think?

Gary Lin

>if (EFI_ERROR(Status)) {
>  DEBUG((DEBUG_INFO, "%a Get SignerCert CommonName failed with status 
> %x\n", __FUNCTION__, Status));
>  return EFI_ABORTED;
> -- 
> 1.9.5.msysgit.1
> 
> ___
> 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] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang

2017-10-16 Thread Ni, Ruiyu

Thanks Steven.

All,
I will check in this patch ASAP.
Because it's just a bug fix in a corner of implementation and it may cause all 
system hang.


-Original Message-
From: Shi, Steven 
Sent: Tuesday, October 17, 2017 10:04 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Laszlo Ersek 
Subject: RE: [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to 
avoid hang

Reviewed-by: Steven Shi 


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, October 17, 2017 9:47 AM
> To: edk2-devel@lists.01.org
> Cc: Shi, Steven ; Laszlo Ersek 
> 
> Subject: [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker 
> to avoid hang
> 
> ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
> MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
> Instead, the actual variable MTRR count should be used.
> Otherwise, the uninitialized random data in MtrrSetting may cause
> MtrrLibSetMemoryType() hang.
> 
> Steven Shi found this bug in QEMU when using Q35 chip.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Steven Shi 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> index 2fd1d0153e..cb22558103 100644
> --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> @@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker (
>  UINTN RangeCount;
>  UINT64MtrrValidBitsMask;
>  UINT64MtrrValidAddressMask;
> +UINT32VariableMtrrCount;
>  MTRR_MEMORY_RANGE Ranges[
>ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 * 
> ARRAY_SIZE (Mtrrs->Variables.Mtrr) + 1
>];
> @@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker (
>return;
>  }
> 
> +VariableMtrrCount = GetVariableMtrrCountWorker ();
> +
>  if (MtrrSetting != NULL) {
>Mtrrs = MtrrSetting;
>  } else {
> @@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker (
>DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, Mtrrs-
> >Fixed.Mtrr[Index]));
>  }
> 
> -for (Index = 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index++) {
> +for (Index = 0; Index < VariableMtrrCount; Index++) {
>if (((MSR_IA32_MTRR_PHYSMASK_REGISTER *)
> >Variables.Mtrr[Index].Mask)->Bits.V == 0) {
>  //
>  // If mask is not valid, then do not display range @@ 
> -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker (
>  RangeCount = 1;
> 
>  MtrrLibGetRawVariableRanges (
> -  >Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr),
> +  >Variables, VariableMtrrCount,
>MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges
>);
>  MtrrLibApplyVariableMtrrs (
> -  RawVariableRanges, ARRAY_SIZE (RawVariableRanges),
> +  RawVariableRanges, VariableMtrrCount,
>Ranges, ARRAY_SIZE (Ranges), 
>);
> 
> --
> 2.12.2.windows.2

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

Re: [edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang

2017-10-16 Thread Shi, Steven

Reviewed-by: Steven Shi 


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, October 17, 2017 9:47 AM
> To: edk2-devel@lists.01.org
> Cc: Shi, Steven ; Laszlo Ersek 
> Subject: [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to
> avoid hang
> 
> ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
> MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
> Instead, the actual variable MTRR count should be used.
> Otherwise, the uninitialized random data in MtrrSetting may cause
> MtrrLibSetMemoryType() hang.
> 
> Steven Shi found this bug in QEMU when using Q35 chip.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Steven Shi 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> index 2fd1d0153e..cb22558103 100644
> --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> @@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker (
>  UINTN RangeCount;
>  UINT64MtrrValidBitsMask;
>  UINT64MtrrValidAddressMask;
> +UINT32VariableMtrrCount;
>  MTRR_MEMORY_RANGE Ranges[
>ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 *
> ARRAY_SIZE (Mtrrs->Variables.Mtrr) + 1
>];
> @@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker (
>return;
>  }
> 
> +VariableMtrrCount = GetVariableMtrrCountWorker ();
> +
>  if (MtrrSetting != NULL) {
>Mtrrs = MtrrSetting;
>  } else {
> @@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker (
>DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, Mtrrs-
> >Fixed.Mtrr[Index]));
>  }
> 
> -for (Index = 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index++) {
> +for (Index = 0; Index < VariableMtrrCount; Index++) {
>if (((MSR_IA32_MTRR_PHYSMASK_REGISTER *)
> >Variables.Mtrr[Index].Mask)->Bits.V == 0) {
>  //
>  // If mask is not valid, then do not display range
> @@ -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker (
>  RangeCount = 1;
> 
>  MtrrLibGetRawVariableRanges (
> -  >Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr),
> +  >Variables, VariableMtrrCount,
>MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges
>);
>  MtrrLibApplyVariableMtrrs (
> -  RawVariableRanges, ARRAY_SIZE (RawVariableRanges),
> +  RawVariableRanges, VariableMtrrCount,
>Ranges, ARRAY_SIZE (Ranges), 
>);
> 
> --
> 2.12.2.windows.2

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

Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.

2017-10-16 Thread Wu, Jiaxin

Hello Karunakar,

Base on your original changes attached in Bugzilla 701 
(https://bugzilla.tianocore.org/show_bug.cgi?id=710), I created the formal 
series patches to support the IPv6 condition check for HTTP/ISCSI. 

Please help to review/verify it.

BTW, To review the ISCSI part, please apply the "[Patch v2 0/2] 
NetworkPkg/IScsiDxe: Display InitiatorInfo correctly" first to avoid any patch 
conflict.

Thanks,
Jiaxin



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, October 17, 2017 9:58 AM
> To: edk2-devel@lists.01.org
> Cc: Karunakar P ; Ye, Ting ;
> Fu, Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
> 
> Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
> we provide this patch to IPv6 condition check by leveraging AIP Protocol.
> 
> Cc: Karunakar P 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Karunakar P 
> Signed-off-by: Wu Jiaxin 
> 
> Jiaxin Wu (2):
>   NetworkPkg/HttpBootDxe: Add IPv6 support condition check.
>   NetworkPkg/IScsiDxe: Add IPv6 support condition check.
> 
>  NetworkPkg/HttpBootDxe/HttpBootDxe.c   | 115
> +++-
>  NetworkPkg/HttpBootDxe/HttpBootDxe.h   |   2 +
>  NetworkPkg/HttpBootDxe/HttpBootDxe.inf |   4 +-
>  NetworkPkg/IScsiDxe/IScsiConfig.c  |  18 +
>  NetworkPkg/IScsiDxe/IScsiDriver.c  |   2 +-
>  NetworkPkg/IScsiDxe/IScsiDriver.h  |   1 +
>  NetworkPkg/IScsiDxe/IScsiDxe.inf   |   2 +
>  NetworkPkg/IScsiDxe/IScsiImpl.h|   1 +
>  NetworkPkg/IScsiDxe/IScsiMisc.c| 135
> -
>  NetworkPkg/IScsiDxe/IScsiMisc.h|   4 +-
>  10 files changed, 278 insertions(+), 6 deletions(-)
> 
> --
> 1.9.5.msysgit.1
> 
> ___
> 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

[edk2] [Patch 2/2] NetworkPkg/IScsiDxe: Add IPv6 support condition check.

2017-10-16 Thread Jiaxin Wu

Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
we provide this patch to IPv6 condition check by leveraging AIP Protocol.

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P 
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiConfig.c |  18 +
 NetworkPkg/IScsiDxe/IScsiDriver.c |   2 +-
 NetworkPkg/IScsiDxe/IScsiDriver.h |   1 +
 NetworkPkg/IScsiDxe/IScsiDxe.inf  |   2 +
 NetworkPkg/IScsiDxe/IScsiImpl.h   |   1 +
 NetworkPkg/IScsiDxe/IScsiMisc.c   | 135 +-
 NetworkPkg/IScsiDxe/IScsiMisc.h   |   4 +-
 7 files changed, 159 insertions(+), 4 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 52e51d6..082020d 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -3419,10 +3419,13 @@ IScsiFormCallback (
   EFI_IP_ADDRESS  Gateway;
   ISCSI_CONFIG_IFR_NVDATA *IfrNvData;
   ISCSI_CONFIG_IFR_NVDATA OldIfrNvData;
   EFI_STATUS  Status;
   EFI_INPUT_KEY   Key;
+  ISCSI_NIC_INFO  *NicInfo;
+
+  NicInfo = NULL;
 
   if ((Action == EFI_BROWSER_ACTION_FORM_OPEN) || (Action == 
EFI_BROWSER_ACTION_FORM_CLOSE)) {
 //
 // Do nothing for UEFI OPEN/CLOSE Action
 //
@@ -3589,10 +3592,25 @@ IScsiFormCallback (
   break;
 
 case KEY_IP_MODE:
   switch (Value->u8) {
   case IP_MODE_IP6:
+NicInfo = IScsiGetNicInfoByIndex (Private->Current->NicIndex); 
+if(!NicInfo->Ipv6Available) {  
+ //
+  // Current NIC doesn't Support IPv6, hence use IPv4.
+  //
+  IfrNvData->IpMode = IP_MODE_IP4;
+   
+  CreatePopUp (
+EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
+,
+L"Current NIC doesn't Support IPv6!",
+NULL
+);
+}
+ 
   case IP_MODE_IP4:
 ZeroMem (IfrNvData->TargetIp, sizeof (IfrNvData->TargetIp));
 Private->Current->AutoConfigureMode = 0;
 
 break;
diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c 
b/NetworkPkg/IScsiDxe/IScsiDriver.c
index 2249919..fbeef97 100644
--- a/NetworkPkg/IScsiDxe/IScsiDriver.c
+++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
@@ -438,11 +438,11 @@ IScsiStart (
   }
   
   //
   // Record the incoming NIC info.
   //
-  Status = IScsiAddNic (ControllerHandle);
+  Status = IScsiAddNic (ControllerHandle, Image);
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
   //
diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.h 
b/NetworkPkg/IScsiDxe/IScsiDriver.h
index 6c6e11b..2db93c5 100644
--- a/NetworkPkg/IScsiDxe/IScsiDriver.h
+++ b/NetworkPkg/IScsiDxe/IScsiDriver.h
@@ -79,10 +79,11 @@ typedef struct {
   UINT8   NicIndex;
   UINT16  VlanId;
   UINTN   BusNumber;
   UINTN   DeviceNumber;
   UINTN   FunctionNumber;
+  BOOLEAN Ipv6Available;
 } ISCSI_NIC_INFO;
 
 typedef struct _ISCSI_PRIVATE_PROTOCOL {
   UINT32  Reserved;
 } ISCSI_PRIVATE_PROTOCOL;
diff --git a/NetworkPkg/IScsiDxe/IScsiDxe.inf b/NetworkPkg/IScsiDxe/IScsiDxe.inf
index 01998a0..319c7fe 100644
--- a/NetworkPkg/IScsiDxe/IScsiDxe.inf
+++ b/NetworkPkg/IScsiDxe/IScsiDxe.inf
@@ -115,18 +115,20 @@
   gEfiIScsiInitiatorNameProtocolGuid
   ## PRODUCES   
   gEfiAuthenticationInfoProtocolGuid
   ## SOMETIMES_CONSUMES
   gEfiAdapterInformationProtocolGuid
+  gEfiNetworkInterfaceIdentifierProtocolGuid_31 ## SOMETIMES_CONSUMES
 
 [Guids]
   gEfiEventExitBootServicesGuid ## SOMETIMES_CONSUMES ## Event
   gEfiIfrTianoGuid  ## SOMETIMES_PRODUCES ## 
UNDEFINED
   gEfiAcpiTableGuid ## SOMETIMES_CONSUMES ## 
SystemTable
   gEfiAcpi10TableGuid   ## SOMETIMES_CONSUMES ## 
SystemTable
   gEfiAcpi20TableGuid   ## SOMETIMES_CONSUMES ## 
SystemTable
   gEfiAdapterInfoNetworkBootGuid## SOMETIMES_CONSUMES ## 
UNDEFINED
+  gEfiAdapterInfoUndiIpv6SupportGuid## SOMETIMES_CONSUMES ## GUID
   
   ## SOMETIMES_PRODUCES ## Variable:L"AttemptOrder"
   ## SOMETIMES_CONSUMES ## Variable:L"AttemptOrder"
   ## SOMETIMES_PRODUCES ## Variable:L"InitialAttemptOrder"
   ## SOMETIMES_CONSUMES ## Variable:L"InitialAttemptOrder"
diff --git a/NetworkPkg/IScsiDxe/IScsiImpl.h b/NetworkPkg/IScsiDxe/IScsiImpl.h
index 741c497..9e36da0 100644
--- a/NetworkPkg/IScsiDxe/IScsiImpl.h
+++ b/NetworkPkg/IScsiDxe/IScsiImpl.h
@@ -37,10 +37,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
index

[edk2] [Patch 1/2] NetworkPkg/HttpBootDxe: Add IPv6 support condition check.

2017-10-16 Thread Jiaxin Wu

Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
we provide this patch to IPv6 condition check by leveraging AIP Protocol.

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P 
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/HttpBootDxe/HttpBootDxe.c   | 115 -
 NetworkPkg/HttpBootDxe/HttpBootDxe.h   |   2 +
 NetworkPkg/HttpBootDxe/HttpBootDxe.inf |   4 +-
 3 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
index 642e0fe..1a67a87 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
@@ -1,9 +1,9 @@
 /** @file
   Driver Binding functions implementation for UEFI HTTP boot.
 
-Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
 http://opensource.org/licenses/bsd-license.php.
  
 
@@ -33,10 +33,106 @@ EFI_DRIVER_BINDING_PROTOCOL gHttpBootIp6DxeDriverBinding = 
{
   HTTP_BOOT_DXE_VERSION,
   NULL,
   NULL
 };
 
+
+
+/**
+  Check whether UNDI protocol supports IPv6.
+
+  @param[in]   ControllerHandle  Controller handle.
+  @param[in]   Private   Pointer to HTTP_BOOT_PRIVATE_DATA.
+  @param[out]  Ipv6Support   TRUE if UNDI supports IPv6.
+
+  @retval EFI_SUCCESSGet the result whether UNDI supports IPv6 by 
NII or AIP protocol successfully.
+  @retval EFI_NOT_FOUND  Don't know whether UNDI supports IPv6 since 
NII or AIP is not available.
+
+**/
+EFI_STATUS
+HttpBootCheckIpv6Support (
+  IN  EFI_HANDLE   ControllerHandle,
+  IN  HTTP_BOOT_PRIVATE_DATA   *Private,
+  OUT BOOLEAN  *Ipv6Support
+  )
+{
+  EFI_HANDLE   Handle;
+  EFI_ADAPTER_INFORMATION_PROTOCOL *Aip;
+  EFI_STATUS   Status;
+  EFI_GUID *InfoTypesBuffer;
+  UINTNInfoTypeBufferCount;
+  UINTNTypeIndex;
+  BOOLEAN  Supported;
+  VOID *InfoBlock;
+  UINTNInfoBlockSize;
+
+  ASSERT (Private != NULL && Ipv6Support != NULL);
+
+  //
+  // Check whether the UNDI supports IPv6 by NII protocol.
+  //
+  if (Private->Nii != NULL) {
+*Ipv6Support = Private->Nii->Ipv6Supported;
+return EFI_SUCCESS;
+  }
+
+  //
+  // Get the NIC handle by SNP protocol.
+  //  
+  Handle = NetLibGetSnpHandle (ControllerHandle, NULL);
+  if (Handle == NULL) {
+return EFI_NOT_FOUND;
+  }
+
+  Aip= NULL;
+  Status = gBS->HandleProtocol (
+  Handle,
+  ,
+  (VOID *) 
+  );
+  if (EFI_ERROR (Status) || Aip == NULL) {
+return EFI_NOT_FOUND;
+  }
+
+  InfoTypesBuffer = NULL;
+  InfoTypeBufferCount = 0;
+  Status = Aip->GetSupportedTypes (Aip, , 
);
+  if (EFI_ERROR (Status) || InfoTypesBuffer == NULL) {
+FreePool (InfoTypesBuffer);
+return EFI_NOT_FOUND;
+  }
+
+  Supported = FALSE;
+  for (TypeIndex = 0; TypeIndex < InfoTypeBufferCount; TypeIndex++) {
+if (CompareGuid ([TypeIndex], 
)) {
+  Supported = TRUE;
+  break;
+}
+  }
+
+  FreePool (InfoTypesBuffer);
+  if (!Supported) {
+return EFI_NOT_FOUND;
+  }
+
+  //
+  // We now have adapter information block.
+  //
+  InfoBlock = NULL;
+  InfoBlockSize = 0;
+  Status = Aip->GetInformation (Aip, , 
, );
+  if (EFI_ERROR (Status) || InfoBlock == NULL) {
+FreePool (InfoBlock);
+return EFI_NOT_FOUND;
+  }  
+
+  *Ipv6Support = ((EFI_ADAPTER_INFO_UNDI_IPV6_SUPPORT *) 
InfoBlock)->Ipv6Support;
+  FreePool (InfoBlock);
+  
+  return EFI_SUCCESS;
+}
+
 /**
   Destroy the HTTP child based on IPv4 stack.
 
   @param[in]  This  Pointer to the EFI_DRIVER_BINDING_PROTOCOL.
   @param[in]  Private   Pointer to HTTP_BOOT_PRIVATE_DATA.
@@ -780,10 +876,11 @@ HttpBootIp6DxeDriverBindingStart (
   EFI_STATUS Status;
   HTTP_BOOT_PRIVATE_DATA *Private;
   EFI_DEV_PATH   *Node;
   EFI_DEVICE_PATH_PROTOCOL   *DevicePath;
   UINT32 *Id;
+  BOOLEANIpv6Available;
   
   Status = gBS->OpenProtocol (
   ControllerHandle,
   ,
   (VOID **) ,
@@ -856,10 +953,26 @@ HttpBootIp6DxeDriverBindingStart (
 if (EFI_ERROR (Status)) {
   goto ON_ERROR;
 }
   
   }
+
+  //
+  // Set IPv6 available flag.
+  // 
+  Status =

[edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang

2017-10-16 Thread Ruiyu Ni

ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
Instead, the actual variable MTRR count should be used.
Otherwise, the uninitialized random data in MtrrSetting may cause
MtrrLibSetMemoryType() hang.

Steven Shi found this bug in QEMU when using Q35 chip.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Steven Shi 
Cc: Laszlo Ersek 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 2fd1d0153e..cb22558103 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker (
 UINTN RangeCount;
 UINT64MtrrValidBitsMask;
 UINT64MtrrValidAddressMask;
+UINT32VariableMtrrCount;
 MTRR_MEMORY_RANGE Ranges[
   ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 * ARRAY_SIZE 
(Mtrrs->Variables.Mtrr) + 1
   ];
@@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker (
   return;
 }
 
+VariableMtrrCount = GetVariableMtrrCountWorker ();
+
 if (MtrrSetting != NULL) {
   Mtrrs = MtrrSetting;
 } else {
@@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker (
   DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, 
Mtrrs->Fixed.Mtrr[Index]));
 }
 
-for (Index = 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index++) {
+for (Index = 0; Index < VariableMtrrCount; Index++) {
   if (((MSR_IA32_MTRR_PHYSMASK_REGISTER 
*)>Variables.Mtrr[Index].Mask)->Bits.V == 0) {
 //
 // If mask is not valid, then do not display range
@@ -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker (
 RangeCount = 1;
 
 MtrrLibGetRawVariableRanges (
-  >Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr),
+  >Variables, VariableMtrrCount,
   MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges
   );
 MtrrLibApplyVariableMtrrs (
-  RawVariableRanges, ARRAY_SIZE (RawVariableRanges),
+  RawVariableRanges, VariableMtrrCount,
   Ranges, ARRAY_SIZE (Ranges), 
   );
 
-- 
2.12.2.windows.2

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

Re: [edk2] [PATCH edk2-platforms] Platform/ARM: remove ReportStatusCodeLib resolutions

2017-10-16 Thread Gao, Liming

Ard:
  
MdeModulePkg\Library\RuntimeDxeReportStatusCodeLib\RuntimeDxeReportStatusCodeLib.inf
 is designed for Runtime driver. If you require StatusCode at runtime, you can 
use this library instance. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Tuesday, October 17, 2017 2:04 AM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Cc: Ard Biesheuvel ; sudeep.ho...@arm.com
> Subject: [edk2] [PATCH edk2-platforms] Platform/ARM: remove 
> ReportStatusCodeLib resolutions
> 
> The generic ResetSystemRuntimeDxe may invoke ReportStatusCodeLib, and
> this may happen at runtime. If the chosen resolution is not suitable
> for runtime, this will result in a crash.
> 
> Given that we don't actually use status codes, let's just switch to
> the NULL instance for all modules and be done with it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
> b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> index 8bcb84869c84..b758c58c9872 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> @@ -153,7 +153,7 @@
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> 
> -  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> +  
> ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
> 
>  [LibraryClasses.common.SEC]
>
> ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
> @@ -182,7 +182,6 @@
>
> MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
>PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
>PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
> -  
> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>
> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
>
> ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf
> 
> @@ -195,7 +194,6 @@
>
> MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
>PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
>PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
> -  
> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>
> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
>
> PeiResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf
>
> ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf
> @@ -358,8 +356,6 @@
>#  DEBUG_ERROR 0x8000  // Error
>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x800F
> 
> -  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
> -
>gEmbeddedTokenSpaceGuid.PcdEmbeddedAutomaticBootCommand|""
>gEmbeddedTokenSpaceGuid.PcdEmbeddedDefaultTextColor|0x07
>gEmbeddedTokenSpaceGuid.PcdEmbeddedMemVariableStoreSize|0x1
> --
> 2.11.0
> 
> ___
> 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] ShellPkg/UefiShellLib: Use a more bright blue/green color

2017-10-16 Thread Tim Lewis

And we always turn off the multiple colors. Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Jarlstrom, Laurie
Sent: Monday, October 16, 2017 12:47 PM
To: Carsey, Jaben ; Ni, Ruiyu ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
color

The Idea of PCDs would be great.  I always change the UefiShellLib EFI_BLUE to 
EFI_CYAN to get a brighter blue.

thanks,
Laurie
 
laurie.jarlst...@intel.com

Intel SSG/STO/EBP
(503) 712-9395


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Monday, October 16, 2017 9:32 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
color

Reviewed-by: Jaben Carsey 

We could also use some PCDs if different people really want different colors in 
the future...

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 16, 2017 12:31 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
> color
> Importance: High
> 
> Some developers/QAs complain the color of directory or executable 
> files is hard to see and suggest to use a more bright color.
> I agree with this suggestion so make this patch.
> The look and feel is much better now.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 64565f81d8..25d3e33533 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
>  gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_WHITE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'B'):
> -gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_BLUE,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTBLUE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'V'):
> -gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_GREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTGREEN,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>default:
>  //
> --
> 2.12.2.windows.2

___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color

2017-10-16 Thread Jarlstrom, Laurie

The Idea of PCDs would be great.  I always change the UefiShellLib EFI_BLUE to 
EFI_CYAN to get a brighter blue.

thanks,
Laurie
 
laurie.jarlst...@intel.com

Intel SSG/STO/EBP
(503) 712-9395


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Monday, October 16, 2017 9:32 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
color

Reviewed-by: Jaben Carsey 

We could also use some PCDs if different people really want different colors in 
the future...

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 16, 2017 12:31 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green 
> color
> Importance: High
> 
> Some developers/QAs complain the color of directory or executable 
> files is hard to see and suggest to use a more bright color.
> I agree with this suggestion so make this patch.
> The look and feel is much better now.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 64565f81d8..25d3e33533 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
>  gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_WHITE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'B'):
> -gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_BLUE,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTBLUE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'V'):
> -gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_GREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTGREEN,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>default:
>  //
> --
> 2.12.2.windows.2

___
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 v5 0/2] Enhanced SMM support for AMD-based x86 systems.

2017-10-16 Thread Duran, Leo



> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 16, 2017 1:44 PM
> To: Duran, Leo ; Yao, Jiewen
> 
> Cc: edk2-devel@lists.01.org; Paolo Bonzini 
> Subject: Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based
> x86 systems.
> 
> On 10/16/17 19:31, Duran, Leo wrote:
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Monday, October 16, 2017 12:06 PM
> >> To: Yao, Jiewen ; Duran, Leo
> >> 
> >> Cc: edk2-devel@lists.01.org; Paolo Bonzini 
> >> Subject: Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-
> based
> >> x86 systems.
> >>
> >> On 10/15/17 02:58, Yao, Jiewen wrote:
> >>> for runtime test, I recommend using ovmf. You don't need real
> hardware.
> >> It can run both 32bit or 64bit. It can run in both Linux and windows.
> >>>
> >>> You need use -D SMM_REQUIRE option to build ovmf.
> >>> If you have any problem, Laszlo is the good contact.
> >>
> >> I don't have much context about this series, but looking at the
> >> blurb, I see that version 3 removed OvmfPkg patches:
> >>
> >>> Changes since v2:
> >>> The intent of this revision is to maintain compatibility with
> >>> existing packages. To that end, changes to OvmgfPkg and QuarkSocPkg
> >>> are reverted. Moreover, pertinent macros are replaced in the C code,
> >>> rather than on header files that are shared globally.
> >>
> >> Judged on the diffstat of patch #1 -- only
> >> "UefiCpuPkg/Library/SmmCpuFeaturesLib" files are modified -- I would
> >> say that changes in patch #1 are invisible to OVMF. The reason is
> >> that OVMF uses a separate SmmCpuFeaturesLib instance, namely
> >>
> >>   OvmfPkg/Library/SmmCpuFeaturesLib
> >>
> >> This means two things:
> >>
> >> - changes from patch #1 cannot be tested with OVMF, simply because
> >>   "UefiCpuPkg/Library/SmmCpuFeaturesLib" is never built for OVMF;
> >>
> >> - changes from patch #2 may or may not break SMM in OVMF, dependent
> on
> >>   whether patch #2 is tied closely to patch #1.
> >>
> >> In order to see why OvmfPkg has a separate SmmCpuFeaturesLib
> >> instance, please review the commit log:
> >>
> >>   git log --reverse -- OvmfPkg/Library/SmmCpuFeaturesLib
> >>
> >> At this point I cannot determine if this patch set should ignore
> >> OvmfPkg completely, or else patch #1 should be duplicated for
> >> "OvmfPkg/Library/SmmCpuFeaturesLib" as well. (I guess I don't
> >> understand the goal of the patch set -- I've read the blurb, but the
> >> problem has not been stated well enough for me to understand. Or
> >> maybe it was stated long ago, and I've forgotten it :) )
> >>
> >
> > Lazlo,
> > I purposely left out changes to OVMF and Quark, consistent with previous
> feedback.
> 
> I've found my previous comments:
> 
> http://mid.mail-archive.com/2d3efa5a-ad72-bb35-1e6a-
> b9b783793...@redhat.com
> 
> There I only suggested a different (more telling) subject for the OvmfPkg
> patch, and wrote,
> 
> > (Of course I realize the patch might entirely be replaced in the next
> > version, based on Jiewen's and Mike's feedback -- that's OK with me, I
> > just wanted to give an example.)
> 
> I didn't try to validate Jiewen's / Mike's feedback; I just stated *if*, 
> according
> to them, patching OvmfPkg was not necessary, I'd be OK with that.
> 
> Since we're talking anyway, can you (and/or Jiewen & Mike) please state the
> problem being solved here, and explain why patching the
> SmmCpuFeaturesLib instance in OvmfPkg is, or is not, necessary to update?
> 
> Hmmm... Is it the case that
> 
>   UefiCpuPkg/Library/SmmCpuFeaturesLib
> 
> runs correctly on Intel *hosts* only at the moment (so it needs fixing, for
> AMD *hosts*), while
> 
>   OvmfPkg/Library/SmmCpuFeaturesLib
> 
> deals with AMD-looking *guests* anyway, so it needs no fixing, for AMD
> compatibility?
> 
> If this is correct, then I agree patch #1 does not need to be duplicated for
> OvmfPkg.

Lazlo,
Yes, that is my understanding.

> 
> *However*, in turn, patch #2 (for PiSmmCpuDxeSmm) might be necessary to
> update for QEMU. PiSmmCpuDxeSmm runs on both bare metal and on
> QEMU.
> And, as Paolo says, a pure CPUID / manufacturer check (for determining the
> state save layout) is wrong on QEMU, even if the same would work on bare
> metal:
> 
> @@ -547,6 +595,20 @@ PiCpuSmmEntry (
>  );
> 
>//
> +  // Override SMRAM offsets for AMD
> +  //
> +  if (StandardSignatureIsAuthenticAMD ()) {
> +gSmmSmramStateMapOffset =
> AMD_SMRAM_SAVE_STATE_MAP_OFFSET;
> +gSmmPsdOffset = AMD_SMM_PSD_OFFSET;  }
> +
> 
> If patch v5 2/2 is merely a refactoring (i.e., it causes PiSmmCpuDxeSmm to
> behave exactly the same as before, just with an improved implementation),
> then I agree a CPUID-based check is not necessarily a bug (regression).
> Instead, it might be called a missed opportunity (or, more nicely put, a
>

Re: [edk2] SecurityPkg: untrusted OptionRom is loaded despite DENY_EXECUTE_ON_SECURITY_VIOLATION set.

2017-10-16 Thread Laszlo Ersek

On 10/16/17 18:57, Zmuda, Wojciech wrote:
> Hello,
>
> I'd like to ask you for help with understanding Secure Boot policy
> mechanism, specifically DENY_EXECUTE_ON_SECURITY_VIOLATION for
> PcdOptionRomImageVerificationPolicy. The OptionROM in my setup is
> loaded while, in my opinion, it should be rejected.
>
> I'm testing the following scenario: Secure Boot is enabled with my own
> PK and KEK enrolled, but with no db, to make sure nothing unsigned or
> signed by somebody else but me can be executed. A PCIe card with
> OptionROM (some EBC code) is installed.
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy  is
> set to 0x04 in my platform's package. What I expect, is the OptionROM
> execution being denied, as it is not signed by my certificate. What I
> observe, on the other hand, is a message on the console, that no EBC
> interpreter is found, which suggest, that the  OptionROM is loaded,
> just fails at the execution of EBC. The same message is printed when
> Secure Boot is disabled.
>
> I tried to understand the code by stepping through it in the DS-5. The
> following part of
> SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> seems suspicious to me:
>
> SecurityStatus = gSecurity->FileAuthenticationState (
>   gSecurity,
>   AuthenticationStatus,
>   OriginalFilePath
>   );
>   }

This code is not from "DxeImageVerificationLib.c"; it is from
CoreLoadImageCommon() in "MdeModulePkg/Core/Dxe/Image/Image.c". With
more context:

  } else if ((gSecurity != NULL) && (OriginalFilePath != NULL)) {
//
// Verify the Authentication Status through the Security Architectural 
Protocol
//
SecurityStatus = gSecurity->FileAuthenticationState (
  gSecurity,
  AuthenticationStatus,
  OriginalFilePath
  );
  }

>
>   //
>   // Check Security Status.
>   //
>   if (EFI_ERROR (SecurityStatus) && SecurityStatus != EFI_SECURITY_VIOLATION) 
> {
> if (SecurityStatus == EFI_ACCESS_DENIED) {
>   //
>   // Image was not loaded because the platform policy prohibits the image 
> from being loaded.
>   // It's the only place we could meet EFI_ACCESS_DENIED.
>   //
>   *ImageHandle = NULL;
> }
> Status = SecurityStatus;
> Image = NULL;
> goto Done;
> }
>
> The return code of gSecurity->FileAuthenticationState () (which is
> implemented in
> MdeModulePkg/Core/Dxe/Image/Image.c:DxeImageVerificationHandler ()),
> is EFI_SECURITY_VIOLATION. Such return code skips this if-statement,
> that prevents the image to be loaded.  According to the comment in the
> if-statement: for the policy to be respected,
> gSecurity->FileAuthenticationState () should return EFI_ACCESS_DENIED.

No, that's a different kind of "platform policy".

The PCD that you mention is indeed platform policy, but only for
DxeImageVerificationLib. The platform policy being referred-to in this
comment is on the level of the gSecurity->FileAuthenticationState()
function call; and for that, we have to review the type definition of
the

  EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState

member function. The type name for this member function is
EFI_SECURITY_FILE_AUTHENTICATION_STATE, and it is defined in
"MdePkg/Include/Protocol/Security.h".

I will not quote the entire description from said header file, just the
part that explains the difference:

>   @retval EFI_SECURITY_VIOLATION The file specified by File did not 
> authenticate, and
> the platform policy dictates that File should 
> be placed
> in the untrusted state. A file may be 
> promoted from
> the untrusted to the trusted state at a 
> future time
> with a call to the Trust() DXE Service.
>   @retval EFI_ACCESS_DENIED The file specified by File did not 
> authenticate, and
> the platform policy dictates that File should 
> not be
> used for any purpose.

Back to your email:

On 10/16/17 18:57, Zmuda, Wojciech wrote:
> That being said, I stepped through DxeImageVerificationHandler (). The
> PCD with OptionROM policy is checked correctly. The function handles
> ALWAYS_EXECUTE and NEVER_EXECUTE policies properly and hangs on
> QUERY_USER_ and ALLOW_EXECUTE_ON_SECURITY_VIOLATION.  This seems fine,
> however there is no code handling the
> DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04) case. Stepping through this
> function shows that the image to be loaded cannot be found in the db
> (correct, as there's no db). Then, the function jumps to its very  end
> and returns EFI_SECURITY_VIOLATION, which skips the aforementioned
> if-statement:
>
> Done:
>   if (Status != EFI_SUCCESS) {

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

2017-10-16 Thread Duran, Leo



> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 16, 2017 12:06 PM
> To: Yao, Jiewen ; Duran, Leo
> 
> Cc: edk2-devel@lists.01.org; Paolo Bonzini 
> Subject: Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based
> x86 systems.
> 
> On 10/15/17 02:58, Yao, Jiewen wrote:
> > for runtime test, I recommend using ovmf. You don't need real hardware.
> It can run both 32bit or 64bit. It can run in both Linux and windows.
> >
> > You need use -D SMM_REQUIRE option to build ovmf.
> > If you have any problem, Laszlo is the good contact.
> 
> I don't have much context about this series, but looking at the blurb, I see
> that version 3 removed OvmfPkg patches:
> 
> > Changes since v2:
> > The intent of this revision is to maintain compatibility with existing
> > packages. To that end, changes to OvmgfPkg and QuarkSocPkg are
> > reverted. Moreover, pertinent macros are replaced in the C code,
> > rather than on header files that are shared globally.
> 
> Judged on the diffstat of patch #1 -- only
> "UefiCpuPkg/Library/SmmCpuFeaturesLib" files are modified -- I would say
> that changes in patch #1 are invisible to OVMF. The reason is that OVMF uses
> a separate SmmCpuFeaturesLib instance, namely
> 
>   OvmfPkg/Library/SmmCpuFeaturesLib
> 
> This means two things:
> 
> - changes from patch #1 cannot be tested with OVMF, simply because
>   "UefiCpuPkg/Library/SmmCpuFeaturesLib" is never built for OVMF;
> 
> - changes from patch #2 may or may not break SMM in OVMF, dependent on
>   whether patch #2 is tied closely to patch #1.
> 
> In order to see why OvmfPkg has a separate SmmCpuFeaturesLib instance,
> please review the commit log:
> 
>   git log --reverse -- OvmfPkg/Library/SmmCpuFeaturesLib
> 
> At this point I cannot determine if this patch set should ignore OvmfPkg
> completely, or else patch #1 should be duplicated for
> "OvmfPkg/Library/SmmCpuFeaturesLib" as well. (I guess I don't understand
> the goal of the patch set -- I've read the blurb, but the problem has not been
> stated well enough for me to understand. Or maybe it was stated long ago,
> and I've forgotten it :) )
> 

Lazlo,
I purposely left out changes to OVMF and Quark, consistent with previous 
feedback.
Leo

> 
> Leo, I have a separate request: the diffstats in the blurb and on patch
> #1 are practically unreadable. This is because edk2 uses long names for files
> and directories, and because the nesting can get deep -- and "git"
> by default truncates the diffstat to quite narrow lines.
> 
> In order to avoid this, I recommend formatting edk2 patch sets as follows:
> 
>   git format-patch --stat=1000 --stat-graph-width=20 ...
> 
Lazlo,
Sounds good. Will do.
Leo.

> This makes the pathname column just as wide as necessary, while keeping
> the actual "stats" column reasonably narrow.
> 
> Thanks,
> Laszlo
> 
> >> 在 2017年10月15日，上午12:04，Duran, Leo 
> 写道：
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Yao, Jiewen [mailto:jiewen@intel.com]
> >>> Sent: Thursday, October 12, 2017 8:53 PM
> >>> To: Duran, Leo ; edk2-devel@lists.01.org
> >>> Subject: RE: [edk2] [PATCH v5 0/2] Enhanced SMM support for
> >>> AMD-based
> >>> x86 systems.
> >>>
> >>> HI Leo
> >>> Thank you very much. This patch looks good to me in general.
> >>>
> >>> Some minor comment:
> >>>
> >>> 1) For AMD smm save state.
> >>> I saw Paolo gave the comment on how to detect AMD save state. I do
> >>> not have strong opinion on that. I think you and Paolo can make
> decision.
> >>>
> >>> I recommend we move AMD_SMRAM_SAVE_STATE_MAP_OFFSET to
> >>> UefiCpuPkg\Include\Register\Amd\SmramSaveStateMap.h, because it
> is
> >>> standard.
> >> Hi Yao,
> >>
> >> Sure thing, I will do that.
> >>
> >> Leo
> >>
> >>> +//
> >>> +// Definitions for AMD systems are based on contents of the //
> >>> +AMD64 Architecture Programmer's Manual // Volume 2: System
> >>> +Programming, Section 10 System-Management Mode // #define
> >>> +AMD_SMRAM_SAVE_STATE_MAP_OFFSET 0xfe00
> >>>
> >>> We can leave AMD_SMM_PSD_OFFSET in
> UefiCpuPkg/PiSmmCpuDxeSmm, if it
> >>> is implementation specific.
> >>> +#define   AMD_SMM_PSD_OFFSET 0xfc00
> >>>
> >>>
> >>>
> >>> 2) For Intel save state, I assume you already did some test to make
> >>> sure there is no regression.
> >>> If so, would you please add some description on what test you have
> done?
> >>> For example,
> >>>If both IA32 and X64 are validated?
> >>>If all three .S, .asm, .nasm are validated?
> >>>If OS boot and S3 resume are validated?
> >>>
> >>> If you did any other test, please also add.
> >>>
> >>
> >> Hi Yao,
> >>
> >> I have not done runtime validation testing.
> >> Instead, I tested the assembly code snippets in a vacuum (in their
> >> .asm, .nasm, and .S forms), to ensure the source produced the expected
> compiled code, and the expected execution.
> >>
> >> So

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

2017-10-16 Thread Paolo Bonzini

On 13/10/2017 03:52, Yao, Jiewen wrote:
> I recommend we move AMD_SMRAM_SAVE_STATE_MAP_OFFSET to 
> UefiCpuPkg\Include\Register\Amd\SmramSaveStateMap.h, because it is standard.
> +//
> +// Definitions for AMD systems are based on contents of the
> +// AMD64 Architecture Programmer's Manual
> +// Volume 2: System Programming, Section 10 System-Management Mode
> +//
> +#define AMD_SMRAM_SAVE_STATE_MAP_OFFSET  0xfe00

If I understand correctly, I think AMD can keep on using 0xfc00 and just 
adjust the offsets up by 0x200 bytes.  For example, QEMU_SMRAM_SAVE_STATE_MAP
in OvmfPkg/Include/Register/QemuSmramStateSaveMap.h is essentially the AMD
format and it starts with:

  UINT8   Reserved0[0x200]; // 7c00h
  UINT8   Reserved1[0xf8];  // 7e00h

See also the comment in SMRAM_SAVE_STATE_MAP32:

  UINT8   Reserved[0x200];  // 7c00h
// Padded an extra 0x200 bytes so 32-bit and 64-bit
// SMRAM Save State Maps are the same size
  UINT8   Reserved1[0xf8];  // 7e00h

Thanks,

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

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

2017-10-16 Thread Paolo Bonzini

On 16/10/2017 19:06, Laszlo Ersek wrote:
>   git log --reverse -- OvmfPkg/Library/SmmCpuFeaturesLib
> 
> At this point I cannot determine if this patch set should ignore OvmfPkg
> completely, or else patch #1 should be duplicated for
> "OvmfPkg/Library/SmmCpuFeaturesLib" as well. (I guess I don't understand
> the goal of the patch set -- I've read the blurb, but the problem has
> not been stated well enough for me to understand. Or maybe it was stated
> long ago, and I've forgotten it :) )

I _think_ they should be duplicated, but I also don't understand the
goal and that is just from reasoning on why OVMF has a separate
SmmCpuFeaturesLib implementation.

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

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

2017-10-16 Thread Laszlo Ersek

On 10/15/17 02:58, Yao, Jiewen wrote:
> for runtime test, I recommend using ovmf. You don't need real hardware. It 
> can run both 32bit or 64bit. It can run in both Linux and windows.
> 
> You need use -D SMM_REQUIRE option to build ovmf. 
> If you have any problem, Laszlo is the good contact.

I don't have much context about this series, but looking at the blurb, I
see that version 3 removed OvmfPkg patches:

> Changes since v2:
> The intent of this revision is to maintain compatibility with existing
> packages. To that end, changes to OvmgfPkg and QuarkSocPkg are
> reverted. Moreover, pertinent macros are replaced in the C code,
> rather than on header files that are shared globally.

Judged on the diffstat of patch #1 -- only
"UefiCpuPkg/Library/SmmCpuFeaturesLib" files are modified -- I would say
that changes in patch #1 are invisible to OVMF. The reason is that OVMF
uses a separate SmmCpuFeaturesLib instance, namely

  OvmfPkg/Library/SmmCpuFeaturesLib

This means two things:

- changes from patch #1 cannot be tested with OVMF, simply because
  "UefiCpuPkg/Library/SmmCpuFeaturesLib" is never built for OVMF;

- changes from patch #2 may or may not break SMM in OVMF, dependent on
  whether patch #2 is tied closely to patch #1.

In order to see why OvmfPkg has a separate SmmCpuFeaturesLib instance,
please review the commit log:

  git log --reverse -- OvmfPkg/Library/SmmCpuFeaturesLib

At this point I cannot determine if this patch set should ignore OvmfPkg
completely, or else patch #1 should be duplicated for
"OvmfPkg/Library/SmmCpuFeaturesLib" as well. (I guess I don't understand
the goal of the patch set -- I've read the blurb, but the problem has
not been stated well enough for me to understand. Or maybe it was stated
long ago, and I've forgotten it :) )


Leo, I have a separate request: the diffstats in the blurb and on patch
#1 are practically unreadable. This is because edk2 uses long names for
files and directories, and because the nesting can get deep -- and "git"
by default truncates the diffstat to quite narrow lines.

In order to avoid this, I recommend formatting edk2 patch sets as follows:

  git format-patch --stat=1000 --stat-graph-width=20 ...

This makes the pathname column just as wide as necessary, while keeping
the actual "stats" column reasonably narrow.

Thanks,
Laszlo

>> 在 2017年10月15日，上午12:04，Duran, Leo  写道：
>>
>>
>>
>>> -Original Message-
>>> From: Yao, Jiewen [mailto:jiewen@intel.com]
>>> Sent: Thursday, October 12, 2017 8:53 PM
>>> To: Duran, Leo ; edk2-devel@lists.01.org
>>> Subject: RE: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based
>>> x86 systems.
>>>
>>> HI Leo
>>> Thank you very much. This patch looks good to me in general.
>>>
>>> Some minor comment:
>>>
>>> 1) For AMD smm save state.
>>> I saw Paolo gave the comment on how to detect AMD save state. I do not
>>> have strong opinion on that. I think you and Paolo can make decision.
>>>
>>> I recommend we move AMD_SMRAM_SAVE_STATE_MAP_OFFSET to
>>> UefiCpuPkg\Include\Register\Amd\SmramSaveStateMap.h, because it is
>>> standard.
>> Hi Yao,
>>
>> Sure thing, I will do that.
>>
>> Leo
>>
>>> +//
>>> +// Definitions for AMD systems are based on contents of the // AMD64
>>> +Architecture Programmer's Manual // Volume 2: System Programming,
>>> +Section 10 System-Management Mode // #define
>>> +AMD_SMRAM_SAVE_STATE_MAP_OFFSET 0xfe00
>>>
>>> We can leave AMD_SMM_PSD_OFFSET in UefiCpuPkg/PiSmmCpuDxeSmm,
>>> if it is implementation specific.
>>> +#define   AMD_SMM_PSD_OFFSET 0xfc00
>>>
>>>
>>>
>>> 2) For Intel save state, I assume you already did some test to make sure
>>> there is no regression.
>>> If so, would you please add some description on what test you have done?
>>> For example,
>>>If both IA32 and X64 are validated?
>>>If all three .S, .asm, .nasm are validated?
>>>If OS boot and S3 resume are validated?
>>>
>>> If you did any other test, please also add.
>>>
>>
>> Hi Yao,
>>
>> I have not done runtime validation testing.
>> Instead, I tested the assembly code snippets in a vacuum (in their .asm, 
>> .nasm, and .S forms),
>> to ensure the source produced the expected compiled code, and the expected 
>> execution.
>>
>> So any runtime 'Tested-by' would be greatly appreciated
>> Thanks,
>> Leo.
>>
>>> Thank you
>>> Yao Jiewen
>>>
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Leo Duran
 Sent: Thursday, October 12, 2017 3:45 AM
 To: edk2-devel@lists.01.org
 Subject: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86
 systems.

 This patch-set replaces Intel-specific macros with global variables to
 provide support for AMD-based x86 systems.

 The replaced macros are:
 1) SRAM_SAVE_STATE_MAP_OFFSET
 2) TXT_SMM_PSD_OFFSET
 3) SMM_PSD_OFFSET

 Changes since v4:
 Make runtime CPUID checks and use global

[edk2] SecurityPkg: untrusted OptionRom is loaded despite DENY_EXECUTE_ON_SECURITY_VIOLATION set.

2017-10-16 Thread Zmuda, Wojciech

Hello,

I'd like to ask you for help with understanding Secure Boot policy mechanism, 
specifically DENY_EXECUTE_ON_SECURITY_VIOLATION for 
PcdOptionRomImageVerificationPolicy. The OptionROM in my setup is loaded while, 
in my opinion, it should be rejected.

I'm testing the following scenario: Secure Boot is enabled with my own PK and 
KEK enrolled, but with no db, to make sure nothing unsigned or signed by 
somebody else but me can be executed. A PCIe card with OptionROM (some EBC 
code) is installed. 
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy  is set to 
0x04 in my platform's package. What I expect, is the OptionROM execution being 
denied, as it is not signed by my certificate. What I observe, on the other 
hand, is a message on the console, that no EBC interpreter is found, which 
suggest, that the  OptionROM is loaded, just fails at the execution of EBC. The 
same message is printed when Secure Boot is disabled.

I tried to understand the code by stepping through it in the DS-5. The 
following part of 
SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c seems 
suspicious to me:

    SecurityStatus = gSecurity->FileAuthenticationState (
  gSecurity,
  AuthenticationStatus,
  OriginalFilePath
  );
  }

  //
  // Check Security Status.
  //
  if (EFI_ERROR (SecurityStatus) && SecurityStatus != EFI_SECURITY_VIOLATION) {
    if (SecurityStatus == EFI_ACCESS_DENIED) {
  //
  // Image was not loaded because the platform policy prohibits the image 
from being loaded.
  // It's the only place we could meet EFI_ACCESS_DENIED.
  //
  *ImageHandle = NULL;
    }
    Status = SecurityStatus;
    Image = NULL;
    goto Done;
}

The return code of gSecurity->FileAuthenticationState () (which is implemented 
in MdeModulePkg/Core/Dxe/Image/Image.c:DxeImageVerificationHandler ()), is 
EFI_SECURITY_VIOLATION. Such return code skips this if-statement, that prevents 
the image to be loaded.  According to the comment in the if-statement: for the 
policy to be respected, gSecurity->FileAuthenticationState () should return 
EFI_ACCESS_DENIED.

That being said, I stepped through DxeImageVerificationHandler (). The PCD with 
OptionROM policy is checked correctly. The function handles ALWAYS_EXECUTE and 
NEVER_EXECUTE policies properly and hangs on QUERY_USER_ and 
ALLOW_EXECUTE_ON_SECURITY_VIOLATION.  This seems fine, however there is no code 
handling the DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04) case. Stepping through 
this function shows that the image to be loaded cannot be found in the db 
(correct, as there's no db). Then, the function jumps to its very  end and 
returns EFI_SECURITY_VIOLATION, which skips the aforementioned if-statement:

Done:
  if (Status != EFI_SUCCESS) {
    //
    // Policy decides to defer or reject the image; add its information in 
image executable information table.
    //
    NameStr = ConvertDevicePathToText (File, FALSE, TRUE);
    AddImageExeInfo (Action, NameStr, File, SignatureList, SignatureListSize);
    if (NameStr != NULL) {
  DEBUG((EFI_D_INFO, "The image doesn't pass verification: %s\n", NameStr));
  FreePool(NameStr);
    }
    Status = EFI_SECURITY_VIOLATION;
  }

  if (SignatureList != NULL) {
    FreePool (SignatureList);
  }

  return Status;
}

Is there anything I'm doing wrong trying to prevent untrusted OptionROM 
execution? If my understanding is correct, my case should make 
DxeImageVerificationHandler () return EFI_ACCESS_DENIED here. For example, in 
the snippet above, Status should be set to EFI_ACCESS_DENIED  if Policy == 
DENY_EXECUTE_ON_SECURITY_VIOLATION.

Thank you all for your time,
Wojciech Zmuda


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

[edk2] [PATCH] Platforms/AMD/OverDrive: make capsule support conditional

2017-10-16 Thread Ard Biesheuvel

The signed capsule update support added to the Overdrive platform in
a recent patch inadvertently introduced a dependency on the external
OpenSSL library, which many users may not have installed into their
EDK2 tree by default. So add a DO_CAPSULE variable that defaults to
FALSE, and only build the capsule pieces if it is set to TRUE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 9 +
 Platform/AMD/OverdriveBoard/OverdriveBoard.fdf | 9 -
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index a15f96d2fba9..8620f6be3514 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -23,6 +23,7 @@ DEFINE DO_PSCI  = 1
 DEFINE DO_ISCP  = 1
 DEFINE DO_KCS   = 1
 DEFINE DO_FLASHER   = FALSE
+DEFINE DO_CAPSULE   = FALSE
 
   PLATFORM_NAME  = Overdrive
   PLATFORM_GUID  = B2296C02-9DA1-4CD1-BD48-4D4F0F1276EB
@@ -124,6 +125,7 @@ DEFINE DO_FLASHER   = FALSE
   
RealTimeClockLib|Silicon/AMD/Styx/Library/RealTimeClockLib/RealTimeClockLib.inf
 
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+!if $(DO_CAPSULE) == TRUE
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
@@ -131,6 +133,7 @@ DEFINE DO_FLASHER   = FALSE
   
FmpAuthenticationLib|SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
   IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
   
PlatformFlashAccessLib|Silicon/AMD/Styx/Library/StyxPlatformFlashAccessLib/StyxPlatformFlashAccessLib.inf
+!endif
 
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   
PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -507,6 +510,8 @@ DEFINE DO_FLASHER   = FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0x0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0x0
 
+!if $(DO_CAPSULE) == TRUE
+
 [PcdsDynamicExDefault.common.DEFAULT]
   
gEfiSignedCapsulePkgTokenSpaceGuid.PcdEdkiiSystemFirmwareImageDescriptor|{0x0}|VOID*|0x100
 
@@ -516,6 +521,8 @@ DEFINE DO_FLASHER   = FALSE
   # d34b3d29-0085-4ab3-8be8-84188cc50489
   gEfiMdeModulePkgTokenSpaceGuid.PcdSystemFmpCapsuleImageTypeIdGuid|{0x29, 
0x3d, 0x4b, 0xd3, 0x85, 0x0, 0xb3, 0x4a, 0x8b, 0xe8, 0x84, 0x18, 0x8c, 0xc5, 
0x04, 0x89}
 
+!endif
+
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|5
 
@@ -763,6 +770,7 @@ DEFINE DO_FLASHER   = FALSE
   }
 !endif
 
+!if $(DO_CAPSULE) == TRUE
   #
   # Firmware update
   #
@@ -770,3 +778,4 @@ DEFINE DO_FLASHER   = FALSE
   SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
   SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf
   
Platform/AMD/OverdriveBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
+!endif
diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
index 18f74b3c46fe..867523da3638 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
@@ -249,11 +249,13 @@ READ_LOCK_STATUS   = TRUE
   #
   INF Silicon/AMD/Styx/Drivers/StyxRngDxe/StyxRngDxe.inf
 
+!if $(DO_CAPSULE) == TRUE
   #
   # Firmware update
   #
   INF MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
   INF 
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
+!endif
 
 [FV.STYX_EFI]
 FvAlignment= 16
@@ -283,8 +285,10 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
   INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
   INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
-  INF RuleOverride = FMP_IMAGE_DESC 
Platform/AMD/OverdriveBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
 
+!if $(DO_CAPSULE) == TRUE
+  INF RuleOverride = FMP_IMAGE_DESC 
Platform/AMD/OverdriveBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
+!endif
 
   FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
 SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = 
TRUE {
@@ -292,6 +296,8 @@ READ_LOCK_STATUS   = TRUE
 }
   }
 
+!if $(DO_CAPSULE) == TRUE
+
 [FV.CapsuleDispatchFv]
 FvAlignment= 16
 ERASE_POLARITY = 1
@@ -359,6 +365,7 @@ CAPSULE_HEADER_INIT_VERSION = 0x1
 
   FMP_PAYLOAD = FmpPayloadSystemFirmwarePkcs7
 
+!endif
 
 

 #
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color

2017-10-16 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

We could also use some PCDs if different people really want different colors in 
the future...

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 16, 2017 12:31 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color
> Importance: High
> 
> Some developers/QAs complain the color of directory or executable
> files is hard to see and suggest to use a more bright color.
> I agree with this suggestion so make this patch.
> The look and feel is much better now.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index 64565f81d8..25d3e33533 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
>  gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_WHITE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'B'):
> -gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_BLUE,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTBLUE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>case (L'V'):
> -gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_GREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
> +gST->ConOut->SetAttribute(gST->ConOut,
> EFI_TEXT_ATTR(EFI_LIGHTGREEN,
> ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
>  break;
>default:
>  //
> --
> 2.12.2.windows.2

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

Re: [edk2] [PATCH] SecurityPkg/Pkcs7Verify: Add the comments to address security problem

2017-10-16 Thread Long, Qin

Thanks, Chao.
The suggested change looks too neutral against this problem. I still prefer to 
keep the original language, which was also cited from the description of this 
spec ECR document. 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Zhang, Chao B 
Sent: Monday, October 16, 2017 10:24 PM
To: Long, Qin ; james.bottom...@hansenpartnership.com
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH] SecurityPkg/Pkcs7Verify: Add the comments to address 
security problem

Qin:
The bellowing checking log is a little confusing to me. 
   The specific problem is that if the supplied hash is a different 
algorithm from the blacklist hash, the hash will be approved even if it should 
have been denied.
 How about changing it to 
The backlist hash check may result in false negative given hashes from 
other different algorithms.
  
 Others are good to me. 
 Reviewed-by : Chao Zhang 

-Original Message-
From: Long, Qin 
Sent: Thursday, October 12, 2017 9:18 AM
To: Zhang, Chao B ; 
james.bottom...@hansenpartnership.com
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [PATCH] SecurityPkg/Pkcs7Verify: Add the comments to address security 
problem

Add the comments to address security problems in the Pkcs7Verify Protocol per 
UEFI 2.7 updates.

The Pkcs7Verifier function VerifySignature() has problematic use cases where it 
might be used to unwittingly bypass security checks.  The specific problem is 
that if the supplied hash is a different algorithm from the blacklist hash, the 
hash will be approved even if it should have been denied. The added comments 
place a strong warning about the problem.
It is possible to use the protocol reliably, either by agreeing a hash to use 
for all time (like sha256) or by looping over all supported hashes when using 
the protocol.

Cc: Chao Zhang 
Cc: James Bottomley 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 MdePkg/Include/Protocol/Pkcs7Verify.h   | 10 +-
 SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c |  8 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/Pkcs7Verify.h 
b/MdePkg/Include/Protocol/Pkcs7Verify.h
index ca5ec75910..eaeda48300 100644
--- a/MdePkg/Include/Protocol/Pkcs7Verify.h
+++ b/MdePkg/Include/Protocol/Pkcs7Verify.h
@@ -6,7 +6,7 @@
   PKCS#7 is a general-purpose cryptographic standard (defined by RFC2315,
   available at http://tools.ietf.org/html/rfc2315).
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under  the terms and conditions of the BSD License that accompanies this 
distribution.
 The full text of the license may be found at @@ -140,6 +140,14 @@ EFI_STATUS
   verifies the signature of the content is valid and signing certificate was 
not revoked
   and is contained within a list of trusted signers.
 
+  Note: because this function uses hashes and the specification contains a 
variety of
+hash choices, you should be aware that the check against the RevokedDb 
list
+will improperly succeed if the signature is revoked using a different 
hash
+algorithm.  For this reason, you should either cycle through all UEFI 
supported
+hashes to see if one is forbidden, or rely on a single hash choice 
only if the
+UEFI signature authority only signs and revokes with a single hash (at 
time
+of writing, this hash choice is SHA256).
+
   @param[in] This Pointer to EFI_PKCS7_VERIFY_PROTOCOL 
instance.
   @param[in] SignaturePoints to buffer containing ASN.1 
DER-encoded PKCS
   detached signature.
diff --git a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c 
b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
index 0da549a6bd..ac83e6d5c2 100644
--- a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
+++ b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
@@ -1321,6 +1321,14 @@ _Exit:
   verifies the signature of the content is valid and signing certificate was 
not revoked
   and is contained within a list of trusted signers.
 
+  Note: because this function uses hashes and the specification contains a 
variety of
+hash choices, you should be aware that the check against the RevokedDb 
list
+will improperly succeed if the signature is revoked using a different 
hash
+algorithm.  For this reason, you should either cycle through all UEFI 
supported
+hashes to see if one is forbidden, or rely on a single hash choice 
only if the
+UEFI signature authority only signs and revokes with a single hash

Re: [edk2] [PATCH] SecurityPkg/Pkcs7Verify: Add the comments to address security problem

2017-10-16 Thread Zhang, Chao B

Qin:
The bellowing checking log is a little confusing to me. 
   The specific problem is that if the supplied hash is a different 
algorithm from the blacklist hash, the hash will be approved even if it should 
have been denied.
 How about changing it to 
The backlist hash check may result in false negative given hashes from 
other different algorithms.
  
 Others are good to me. 
 Reviewed-by : Chao Zhang 

-Original Message-
From: Long, Qin 
Sent: Thursday, October 12, 2017 9:18 AM
To: Zhang, Chao B ; 
james.bottom...@hansenpartnership.com
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [PATCH] SecurityPkg/Pkcs7Verify: Add the comments to address security 
problem

Add the comments to address security problems in the Pkcs7Verify Protocol per 
UEFI 2.7 updates.

The Pkcs7Verifier function VerifySignature() has problematic use cases where it 
might be used to unwittingly bypass security checks.  The specific problem is 
that if the supplied hash is a different algorithm from the blacklist hash, the 
hash will be approved even if it should have been denied. The added comments 
place a strong warning about the problem.
It is possible to use the protocol reliably, either by agreeing a hash to use 
for all time (like sha256) or by looping over all supported hashes when using 
the protocol.

Cc: Chao Zhang 
Cc: James Bottomley 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 MdePkg/Include/Protocol/Pkcs7Verify.h   | 10 +-
 SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c |  8 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/Pkcs7Verify.h 
b/MdePkg/Include/Protocol/Pkcs7Verify.h
index ca5ec75910..eaeda48300 100644
--- a/MdePkg/Include/Protocol/Pkcs7Verify.h
+++ b/MdePkg/Include/Protocol/Pkcs7Verify.h
@@ -6,7 +6,7 @@
   PKCS#7 is a general-purpose cryptographic standard (defined by RFC2315,
   available at http://tools.ietf.org/html/rfc2315).
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under  the terms and conditions of the BSD License that accompanies this 
distribution.
 The full text of the license may be found at @@ -140,6 +140,14 @@ EFI_STATUS
   verifies the signature of the content is valid and signing certificate was 
not revoked
   and is contained within a list of trusted signers.
 
+  Note: because this function uses hashes and the specification contains a 
variety of
+hash choices, you should be aware that the check against the RevokedDb 
list
+will improperly succeed if the signature is revoked using a different 
hash
+algorithm.  For this reason, you should either cycle through all UEFI 
supported
+hashes to see if one is forbidden, or rely on a single hash choice 
only if the
+UEFI signature authority only signs and revokes with a single hash (at 
time
+of writing, this hash choice is SHA256).
+
   @param[in] This Pointer to EFI_PKCS7_VERIFY_PROTOCOL 
instance.
   @param[in] SignaturePoints to buffer containing ASN.1 
DER-encoded PKCS
   detached signature.
diff --git a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c 
b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
index 0da549a6bd..ac83e6d5c2 100644
--- a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
+++ b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c
@@ -1321,6 +1321,14 @@ _Exit:
   verifies the signature of the content is valid and signing certificate was 
not revoked
   and is contained within a list of trusted signers.
 
+  Note: because this function uses hashes and the specification contains a 
variety of
+hash choices, you should be aware that the check against the RevokedDb 
list
+will improperly succeed if the signature is revoked using a different 
hash
+algorithm.  For this reason, you should either cycle through all UEFI 
supported
+hashes to see if one is forbidden, or rely on a single hash choice 
only if the
+UEFI signature authority only signs and revokes with a single hash (at 
time
+of writing, this hash choice is SHA256).
+
   @param[in] This Pointer to EFI_PKCS7_VERIFY_PROTOCOL 
instance.
   @param[in] SignaturePoints to buffer containing ASN.1 
DER-encoded PKCS
   detached signature.
--
2.14.1.windows.1

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

Re: [edk2] [PATCH] SecurityPkg:AuthVariableLib:Implement ECR1707 for Private Auth Variable

2017-10-16 Thread Zhang, Chao B

Gary:
  Thanks for pointing this. Please help to review the patch.

-Original Message-
From: Gary Lin [mailto:g...@suse.com] 
Sent: Monday, October 16, 2017 10:15 AM
To: Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: Re: [edk2] [PATCH] SecurityPkg:AuthVariableLib:Implement ECR1707 for 
Private Auth Variable

On Thu, Oct 12, 2017 at 05:14:25PM +0800, Zhang, Chao B wrote:
> ECR1707 for UEFI2.7 clarified certificate management rule for private 
> time-based
> AuthVariable.Trusted cert rule changed from whole signer's certificate stack 
> to
> top-level issuer cert tbscertificate + SignerCert CN for better management 
> compatibility.
> Hash is used to reduce storage overhead.
> 
> Cc: Long Qin 
> Cc: Chen Chen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Library/AuthVariableLib/AuthService.c | 208 
> ++
>  1 file changed, 171 insertions(+), 37 deletions(-)
> 
> diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
> b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> index a37ec0b..7188ff6 100644
> --- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
> +++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> @@ -1530,6 +1530,85 @@ AuthServiceInternalCompareTimeStamp (
>  }
>  
>  /**
> +  Calculate SHA256 digest of SignerCert CommonName + ToplevelCert 
> tbsCertificate
> +  SignerCert and ToplevelCert are inside the signer certificate chain.
> +
> +  @param[in]  SignerCert  A pointer to SignerCert data.
> +  @param[in]  SignerCertSize  Length of SignerCert data.
> +  @param[in]  TopLevelCertA pointer to TopLevelCert data.
> +  @param[in]  TopLevelCertSizeLength of TopLevelCert data.
> +  @param[out] Sha256Digest   Sha256 digest calculated.
> +
> +  @return EFI_ABORTED  Digest process failed.
> +  @return EFI_SUCCESS  SHA256 Digest is succesfully calculated.
> +
> +**/
> +EFI_STATUS
> +CalculatePrivAuthVarSignChainSHA256Digest(
> +  IN UINT8*SignerCert,
> +  IN UINTNSignerCertSize,
> +  IN UINT8*TopLevelCert,
> +  IN UINTNTopLevelCertSize,
> +  OUTUINT8*Sha256Digest
> +  )
> +{
> +  UINT8   *TbsCert;
> +  UINTN   TbsCertSize;
> +  UINT8   CertCommonName[128];
> +  UINTN   CertCommonNameSize;
> +  BOOLEAN CryptoStatus;
> +  EFI_STATUS  Status;
> +
> +  CertCommonNameSize = sizeof(CertCommonName);
> +
> +  //
> +  // Get SignerCert CommonName
> +  //
> +  Status = X509GetCommonName(SignerCert, SignerCertSize, CertCommonName, 
> );
An error showed while building ovmf with gcc 7.2.1:

SecurityPkg/Library/AuthVariableLib/AuthService.c: In function 
‘CalculatePrivAuthVarSignChainSHA256Digest’:
SecurityPkg/Library/AuthVariableLib/AuthService.c:1567:58: error: pointer 
targets in passing argument 3 of ‘X509GetCommonName’ differ in signedness 
[-Werror=pointer-sign]
   Status = X509GetCommonName(SignerCert, SignerCertSize, CertCommonName, 
);
  ^~
In file included from 
SecurityPkg/Library/AuthVariableLib/AuthServiceInternal.h:34:0,
 from SecurityPkg/Library/AuthVariableLib/AuthService.c:32:
CryptoPkg/Include/Library/BaseCryptLib.h:2202:1: note: expected ‘CHAR8 * {aka 
char *}’ but argument is of type ‘UINT8 * {aka unsigned char *}’
 X509GetCommonName (
 ^
cc1: all warnings being treated as errors

Changing the type of CertCommonName from UINT8 to CHAR8 fixes the
warning.

Cheers,

Gary Lin

> +  if (EFI_ERROR(Status)) {
> +DEBUG((DEBUG_INFO, "%a Get SignerCert CommonName failed with status 
> %x\n", __FUNCTION__, Status));
> +return EFI_ABORTED;
> +  }
> +
> +  //
> +  // Get TopLevelCert tbsCertificate
> +  //
> +  if (!X509GetTBSCert(TopLevelCert, TopLevelCertSize, , 
> )) {
> +DEBUG((DEBUG_INFO, "%a Get Top-level Cert tbsCertificate failed!\n", 
> __FUNCTION__));
> +return EFI_ABORTED;
> +  }
> +
> +  //
> +  // Digest SignerCert CN + TopLevelCert tbsCertificate
> +  //
> +  ZeroMem (Sha256Digest, SHA256_DIGEST_SIZE);
> +  CryptoStatus = Sha256Init (mHashCtx);
> +  if (!CryptoStatus) {
> +return EFI_ABORTED;
> +  }
> +
> +  //
> +  // '\0' is forced in CertCommonName. No overflow issue
> +  //
> +  CryptoStatus = Sha256Update (mHashCtx, CertCommonName, AsciiStrLen((CHAR8 
> *)CertCommonName));
> +  if (!CryptoStatus) {
> +return EFI_ABORTED;
> +  }
> +
> +  CryptoStatus = Sha256Update (mHashCtx, TbsCert, TbsCertSize);
> +  if (!CryptoStatus) {
> +return EFI_ABORTED;
> +  }
> +
> +  CryptoStatus  = Sha256Final (mHashCtx, Sha256Digest);
> +  if (!CryptoStatus) {
> +return EFI_ABORTED;
> +  }
> +
> +  return EFI_SUCCESS;
> +}
> +
> +/**
>

[edk2] [PATCH] SecurityPkg:AuthVariableLib:Fix GCC build error

2017-10-16 Thread Zhang, Chao B

Fix GCC build error

Cc: Long Qin 
Cc: Gary Lin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 7188ff6..1e7872a 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -1564,7 +1564,7 @@ CalculatePrivAuthVarSignChainSHA256Digest(
   //
   // Get SignerCert CommonName
   //
-  Status = X509GetCommonName(SignerCert, SignerCertSize, CertCommonName, 
);
+  Status = X509GetCommonName(SignerCert, SignerCertSize, (CHAR8 
*)CertCommonName, );
   if (EFI_ERROR(Status)) {
 DEBUG((DEBUG_INFO, "%a Get SignerCert CommonName failed with status %x\n", 
__FUNCTION__, Status));
 return EFI_ABORTED;
-- 
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] SecurityPkg/AuthVariableLib: Fix ptr bad arithmetic.

2017-10-16 Thread Laszlo Ersek

On 10/16/17 10:43, chenc2 wrote:
> Use variable instead of sizeof(UINT8) and sizeof(UINT32) to
> avoid bad arithmetic of pointer.
> 
> Cc: chenc2 
> Cc: Wu Hao A 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Cc: Zhang Chao B 
> ---
>  SecurityPkg/Library/AuthVariableLib/AuthService.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
> b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> index 7188ff6008..d6387d5ea6 100644
> --- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
> +++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> @@ -2289,6 +2289,8 @@ VerifyTimeBasedPayload (
>UINT8*CertsInCertDb;
>UINT32   CertsSizeinDb;
>UINT8Sha256Digest[SHA256_DIGEST_SIZE];
> +  UINTNOffset1;
> +  UINTNOffset2;
>  
>//
>// 1. TopLevelCert is the top-level issuer certificate in signature Signer 
> Cert Chain
> @@ -2559,9 +2561,11 @@ VerifyTimeBasedPayload (
>  //
>  // Check hash of signer cert CommonName + Top-level issuer 
> tbsCertificate against data in CertDb
>  //
> +Offset1 = sizeof (UINT8) + sizeof (UINT32);
> +Offset2 = sizeof (UINT8);
>  Status = CalculatePrivAuthVarSignChainSHA256Digest(
> -   SignerCerts + sizeof(UINT8) + sizeof(UINT32),
> -   ReadUnaligned32 ((UINT32 *)(SignerCerts + sizeof(UINT8))),
> +   SignerCerts + Offset1,
> +   ReadUnaligned32 ((UINT32 *)(SignerCerts + Offset2)),
> TopLevelCert,
> TopLevelCertSize,
> Sha256Digest
> @@ -2596,12 +2600,14 @@ VerifyTimeBasedPayload (
>//
>// When adding a new common authenticated variable, always save Hash 
> of cn of signer cert + tbsCertificate of Top-level issuer
>//
> +  Offset1 = sizeof (UINT8) + sizeof (UINT32);
> +  Offset2 = sizeof (UINT8);
>Status = InsertCertsToDb (
>   VariableName,
>   VendorGuid,
>   Attributes,
> - SignerCerts + sizeof(UINT8) + sizeof(UINT32),
> - ReadUnaligned32 ((UINT32 *)(SignerCerts + sizeof(UINT8))),
> + SignerCerts + Offset1,
> + ReadUnaligned32 ((UINT32 *)(SignerCerts + Offset2)),
>   TopLevelCert,
>   TopLevelCertSize
>   );
> 

I don't understand how this patch makes any difference.

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

[edk2] [PATCH] SecurityPkg/AuthVariableLib: Fix ptr bad arithmetic.

2017-10-16 Thread chenc2

Use variable instead of sizeof(UINT8) and sizeof(UINT32) to
avoid bad arithmetic of pointer.

Cc: chenc2 
Cc: Wu Hao A 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Cc: Zhang Chao B 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 7188ff6008..d6387d5ea6 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2289,6 +2289,8 @@ VerifyTimeBasedPayload (
   UINT8*CertsInCertDb;
   UINT32   CertsSizeinDb;
   UINT8Sha256Digest[SHA256_DIGEST_SIZE];
+  UINTNOffset1;
+  UINTNOffset2;
 
   //
   // 1. TopLevelCert is the top-level issuer certificate in signature Signer 
Cert Chain
@@ -2559,9 +2561,11 @@ VerifyTimeBasedPayload (
 //
 // Check hash of signer cert CommonName + Top-level issuer 
tbsCertificate against data in CertDb
 //
+Offset1 = sizeof (UINT8) + sizeof (UINT32);
+Offset2 = sizeof (UINT8);
 Status = CalculatePrivAuthVarSignChainSHA256Digest(
-   SignerCerts + sizeof(UINT8) + sizeof(UINT32),
-   ReadUnaligned32 ((UINT32 *)(SignerCerts + sizeof(UINT8))),
+   SignerCerts + Offset1,
+   ReadUnaligned32 ((UINT32 *)(SignerCerts + Offset2)),
TopLevelCert,
TopLevelCertSize,
Sha256Digest
@@ -2596,12 +2600,14 @@ VerifyTimeBasedPayload (
   //
   // When adding a new common authenticated variable, always save Hash of 
cn of signer cert + tbsCertificate of Top-level issuer
   //
+  Offset1 = sizeof (UINT8) + sizeof (UINT32);
+  Offset2 = sizeof (UINT8);
   Status = InsertCertsToDb (
  VariableName,
  VendorGuid,
  Attributes,
- SignerCerts + sizeof(UINT8) + sizeof(UINT32),
- ReadUnaligned32 ((UINT32 *)(SignerCerts + sizeof(UINT8))),
+ SignerCerts + Offset1,
+ ReadUnaligned32 ((UINT32 *)(SignerCerts + Offset2)),
  TopLevelCert,
  TopLevelCertSize
  );
-- 
2.13.2.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellLib: Use a more bright blue/green color

2017-10-16 Thread Ruiyu Ni

Some developers/QAs complain the color of directory or executable
files is hard to see and suggest to use a more bright color.
I agree with this suggestion so make this patch.
The look and feel is much better now.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 64565f81d8..25d3e33533 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -2849,10 +2849,10 @@ InternalShellPrintWorker(
 gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_WHITE, 
((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
 break;
   case (L'B'):
-gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_BLUE, 
((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
+gST->ConOut->SetAttribute(gST->ConOut, 
EFI_TEXT_ATTR(EFI_LIGHTBLUE, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
 break;
   case (L'V'):
-gST->ConOut->SetAttribute(gST->ConOut, EFI_TEXT_ATTR(EFI_GREEN, 
((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
+gST->ConOut->SetAttribute(gST->ConOut, 
EFI_TEXT_ATTR(EFI_LIGHTGREEN, ((OriginalAttribute&(BIT4|BIT5|BIT6))>>4)));
 break;
   default:
 //
-- 
2.12.2.windows.2

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

Re: [edk2] [Patch] BaseTools: Fix a bug Build directory should relative to WORKSPACE

2017-10-16 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Friday, October 13, 2017 4:32 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: Fix a bug Build directory should relative to
>WORKSPACE
>
>The bug is for build output files it still use mws.join function, it
>cause maybe we will get the build output files in the PACKAGES_PATH
>because mws.join will try WORKSPACE first, if the file doesn't exist
>then try PACKAGES_PATH. But for build output, we expected it should
>relative to WORKSPACE.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/AutoGen/AutoGen.py   | 1 +
> BaseTools/Source/Python/Common/GlobalData.py | 1 +
> BaseTools/Source/Python/Common/String.py | 2 +-
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>b/BaseTools/Source/Python/AutoGen/AutoGen.py
>index f2196fd..2fcd471 100644
>--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>@@ -1796,10 +1796,11 @@ class PlatformAutoGen(AutoGen):
> self._BuildDir = path.join(
> self.WorkspaceDir,
> self.OutputDir,
> self.BuildTarget + "_" + 
> self.ToolChain,
> )
>+GlobalData.gBuildDirectory = self._BuildDir
> return self._BuildDir
>
> ## Return directory of platform makefile
> #
> #   @retval string  Makefile directory
>diff --git a/BaseTools/Source/Python/Common/GlobalData.py
>b/BaseTools/Source/Python/Common/GlobalData.py
>index 45e7ea0..e348e9a 100644
>--- a/BaseTools/Source/Python/Common/GlobalData.py
>+++ b/BaseTools/Source/Python/Common/GlobalData.py
>@@ -54,10 +54,11 @@ gAutoGenPhase = False
> #
> # The Conf dir outside the workspace dir
> #
> gConfDirectory = ''
>
>+gBuildDirectory = ''
> #
> # The relative default database file path
> #
> gDatabasePath = ".cache/build.db"
>
>diff --git a/BaseTools/Source/Python/Common/String.py
>b/BaseTools/Source/Python/Common/String.py
>index 81c053d..4a8c03e 100644
>--- a/BaseTools/Source/Python/Common/String.py
>+++ b/BaseTools/Source/Python/Common/String.py
>@@ -309,11 +309,11 @@ def NormPath(Path, Defines={}):
> Path = ReplaceMacro(Path, Defines)
> #
> # To local path format
> #
> Path = os.path.normpath(Path)
>-if Path.startswith(GlobalData.gWorkspace) and not 
>os.path.exists(Path):
>+if Path.startswith(GlobalData.gWorkspace) and not
>Path.startswith(GlobalData.gBuildDirectory) and not os.path.exists(Path):
> Path = Path[len (GlobalData.gWorkspace):]
> if Path[0] == os.path.sep:
> Path = Path[1:]
> Path = mws.join(GlobalData.gWorkspace, Path)
>
>--
>2.6.1.windows.1

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

Re: [edk2] Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring DHCP server as per RFC3021

2017-10-16 Thread Karunakar P

Hi Siyuan,

Could you please update the status on this.

Thanks,
Karunakar

From: Karunakar P
Sent: Wednesday, September 27, 2017 3:06 PM
To: 'Fu, Siyuan'; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hi Siyuan,

I've filled a New Bug in Bugzilla and following are the details.
https://bugzilla.tianocore.org/show_bug.cgi?id=722

Thanks,
Karunakar

From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Wednesday, September 27, 2017 1:46 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hi, Karunakar

We haven't received requirement for this feature before so we don't have plan 
now. I think you can submit a Bugzilla ticket for this feature request, we will 
follow up to investigate it.

BestRegards
Fu Siyuan

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 4:54 PM
To: Fu, Siyuan >; 
'edk2-devel@lists.01.org' 
>
Cc: Wu, Jiaxin >; Ye, Ting 
>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hi Fu Siyuan,

Thanks for your conformation.

We would like to use /31s to save IPv4 addresses.

When it's a point-to-point link (server to router), the extra network address 
and broadcast address is wasted.
RFC 3021 solves the problem by using a broadcast address of 255.255.255.255 on 
such subnets.

We have a requirement to support this, do you have any plan to support RFC3021 
? Given the requirement time consuming how hard to implement this ?

Thanks,
karunakar

From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, September 25, 2017 1:28 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hi, Karunakar

May I know that whether you have a real requirement that must use the 
point-2-point link in your environment, or you just found this problem in your 
test?

BestRegards
Fu Siyuan

From: Fu, Siyuan
Sent: Monday, September 25, 2017 3:50 PM
To: Karunakar P >; 
'edk2-devel@lists.01.org' 
>
Cc: Wu, Jiaxin >; Ye, Ting 
>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hi, Karunakar

You are correct that EDK2 doesn't support rfc3201.

The most obvious problem that come to my mind is the NetIp4IsUnicast() function 
in NetLib, which has the assumption that the host address part should not be 
all zero or all one (or to say, -1 in the rfc3201). I think that's why the PXE 
failed, but Cent OS could use IP address from the same DHCP server.

This is just an example, there may be some other places in edk2 network stack 
which have the same assumption, I'm not sure about this. Anyway, we never 
considered the point-2-point link in edk2.

BestRegards
Fu Siyuan

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 3:02 PM
To: 'edk2-devel@lists.01.org' 
>
Cc: Wu, Jiaxin >; Fu, Siyuan 
>; Ye, Ting 
>
Subject: Re: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring 
DHCP server as per RFC3021

Hello All,

It is known that current EDKII doesn't support RFC3021, We could see the 
following behavior which is PXE boot fails whereas Cent OS can get IP address 
from the same BIOS.

[Configuration Used]

DHCP server setting under Ubuntu:
1. /etc/dhcp/dhcpd.conf

# RFC3021-Using 31-bit perfixes on IPv4 Point-to-Point Links
subnet 192.168.1.0 netmask 255.255.255.254 {
range 192.168.1.1 192.168.1.1;
next-server 192.168.1.0;
filename "EFI/BOOT/BOOTAA64.EFI";
option subnet-mask 255.255.255.254;
option routers 192.168.1.0;
}

2. /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.0
netmask 255.255.255.254
network 192.168.1.0

If the DHCP server and network interface are set up above configuration. Below 
are my test results and questions

1.   CentOS  7.3 (pre-installed) was able to retrieve IP through DHCP when 
they connect HDD to the SUT where PXE is failing.

2.   Could you please suggest what could be the reason behind this?

Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [Patch v2 2/2] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled.

2017-10-16 Thread Jiaxin Wu

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr 
b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
index d401419..35e8f9a 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
+++ b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
@@ -189,13 +189,14 @@ formset
 flags  = INTERACTIVE,
 key= KEY_DHCP_ENABLE,
 endcheckbox;
 endif;
 
-suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp == 0x01 OR
-   ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6 OR 
+suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6 OR 
ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_AUTOCONFIG;
+   
+grayoutif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp == 0x01;
 string  varid   = ISCSI_CONFIG_IFR_NVDATA.LocalIp,
 prompt  = STRING_TOKEN(STR_ISCSI_LOCAL_IP_ADDRESS),
 help= STRING_TOKEN(STR_ISCSI_IP_ADDRESS_HELP),
 flags   = INTERACTIVE,
 key = KEY_LOCAL_IP,
@@ -218,10 +219,11 @@ formset
 flags   = INTERACTIVE,
 key = KEY_GATE_WAY,
 minsize = IP4_MIN_SIZE,
 maxsize = IP4_MAX_SIZE,
 endstring;
+endif;
 
 endif;
 
 suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_AUTOCONFIG;
 subtitle text = STRING_TOKEN(STR_NULL);
-- 
1.9.5.msysgit.1

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

[edk2] [Patch v2 1/2] NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process.

2017-10-16 Thread Jiaxin Wu

The existing attempt should not trigger the DHCP process if it
doesn't associates with the current NIC. That's incorrect when
displaying the initiator info in attempt page.

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiMisc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
index efd05cf..0a0a3f5 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.c
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
@@ -1992,13 +1992,16 @@ IScsiGetConfigData (
  AttemptTmp
  );
 
   continue;
 }
-  } else if (AttemptTmp->SessionConfigData.InitiatorInfoFromDhcp && 
!AttemptTmp->ValidPath) {
+  } else if (AttemptTmp->SessionConfigData.InitiatorInfoFromDhcp && 
+ !AttemptTmp->ValidPath && 
+ AttemptTmp->NicIndex == mPrivate->CurrentNic) {
 //
-// Get DHCP information for already added, but failed, attempt.
+// If the attempt associates with the current NIC, we can 
+// get DHCP information for already added, but failed, attempt.
 //
 AttemptTmp->DhcpSuccess = FALSE;
 if (!mPrivate->Ipv6Flag && (AttemptTmp->SessionConfigData.IpMode == 
IP_MODE_IP4)) {
   Status = IScsiDoDhcp (Private->Image, Private->Controller, 
AttemptTmp);
   if (!EFI_ERROR (Status)) {
-- 
1.9.5.msysgit.1

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

[edk2] [Patch v2 0/2] NetworkPkg/IScsiDxe: Display InitiatorInfo correctly.

2017-10-16 Thread Jiaxin Wu

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process.
  NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled.

 NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr | 6 --
 NetworkPkg/IScsiDxe/IScsiMisc.c| 7 +--
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
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] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled.

2017-10-16 Thread Wu, Jiaxin

Hi Karunakar,

Thanks the verification, I agree it's another iSCSI bug that exposed by this 
patch. 

In IScsiGetConfigData() function, The existing attempt will always trigger the 
DHCP process if Initiator DHCP enabled no matter it associates with the current 
NIC or not. That's incorrect and unreasonable as you overserved if we display 
the InitiatorInfo in attempt page.

I will send another separated but series patch to fix this issue.

Thanks,
Jiaxin



> -Original Message-
> From: Karunakar P [mailto:karunak...@amiindia.co.in]
> Sent: Friday, October 13, 2017 7:49 PM
> To: Fu, Siyuan ; Wu, Jiaxin ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting 
> Subject: RE: [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt
> page even DHCP enabled.
> 
> Hi Jiaxin/Siyuan,
> 
> I've verified Initiator details with this changes.
> 
> I found an issue like Initiator Details are shown for Connection less NIC
> 
> Please find below details for more details
> 
> [Issue details and steps to reproduce]
> 1. SUT have 2 LAN ports
>   MAC  XX:XX:XX:XX:XX:AA  ->   LAN Cable NOT connected to this port, i.e.
> Link Status is Disconnected
>   MAC  XX:XX:XX:XX:XX:BB  ->   LAN Cable Connected to this port,  i.e. 
> Link
> Status is Connected
> 
> 2. I've added two attempts
>a. Attempt1 added to connection less NIC (MAC  XX:XX:XX:XX:XX:AA  )
>b. Attempt2 added to connected NIC (MAC  XX:XX:XX:XX:XX:BB  )
> 
> [Observations]
> 1. Initiator IP Address and Subnet Mask displayed for both Attempt1 and
> Attempt2
> 
> Could you please comment on this observation?
> 
> Thanks,
> Karunakar
> 
> -Original Message-
> From: Fu, Siyuan [mailto:siyuan...@intel.com]
> Sent: Friday, October 13, 2017 11:54 AM
> To: Wu, Jiaxin; edk2-devel@lists.01.org
> Cc: Karunakar P; Ye, Ting
> Subject: RE: [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt
> page even DHCP enabled.
> 
> Reviewed-by: Fu Siyuan 
> 
> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, October 13, 2017 2:01 PM
> To: edk2-devel@lists.01.org
> Cc: Karunakar P ; Ye, Ting ;
> Fu, Siyuan ; Wu, Jiaxin 
> Subject: [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page
> even DHCP enabled.
> 
> Cc: Karunakar P 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
> b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
> index d401419..35e8f9a 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
> +++ b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
> @@ -189,13 +189,14 @@ formset
>  flags  = INTERACTIVE,
>  key= KEY_DHCP_ENABLE,
>  endcheckbox;
>  endif;
> 
> -suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp ==
> 0x01 OR
> -   ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6 OR
> +suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6
> OR
> ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode ==
> IP_MODE_AUTOCONFIG;
> +
> +grayoutif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp ==
> 0x01;
>  string  varid   = ISCSI_CONFIG_IFR_NVDATA.LocalIp,
>  prompt  = STRING_TOKEN(STR_ISCSI_LOCAL_IP_ADDRESS),
>  help= STRING_TOKEN(STR_ISCSI_IP_ADDRESS_HELP),
>  flags   = INTERACTIVE,
>  key = KEY_LOCAL_IP,
> @@ -218,10 +219,11 @@ formset
>  flags   = INTERACTIVE,
>  key = KEY_GATE_WAY,
>  minsize = IP4_MIN_SIZE,
>  maxsize = IP4_MAX_SIZE,
>  endstring;
> +endif;
> 
>  endif;
> 
>  suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode ==
> IP_MODE_AUTOCONFIG;
>  subtitle text = STRING_TOKEN(STR_NULL);
> --
> 1.9.5.msysgit.1

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

38 matches

Mail list logo