Date   

[PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

Ashraf Ali S
 

[edk2-devel] [PATCH]
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506

Build Scrips for Reset Vector currently based on Python 2
which is already EOL, needs to modify the build script based on
Python 3, update the Binary accordingly.

Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Cc: Sangeetha V <sangeetha.v@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
---
.../Vtf0/Bin/ResetVector.ia32.port80.raw | Bin 516 -> 484 bytes
.../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
.../Vtf0/Bin/ResetVector.ia32.serial.raw | Bin 884 -> 868 bytes
.../Vtf0/Bin/ResetVector.x64.port80.raw | Bin 28676 -> 28676 bytes
.../ResetVector/Vtf0/Bin/ResetVector.x64.raw | Bin 28676 -> 28676 bytes
.../Vtf0/Bin/ResetVector.x64.serial.raw | Bin 28676 -> 28676 bytes
UefiCpuPkg/ResetVector/Vtf0/Build.py | 11 +++++++----
.../Vtf0/Tools/FixupForRawSection.py | 4 ++--
8 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
index 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9aeae21ff04d91d 100644
GIT binary patch
delta 410
zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>P<pEKFmr@L>EYMB8#X*^*s&i7
zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqO<t>wyxZ<^$|Sx+*`qBE-KP
zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw&BCG
zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
z`2b5=qlIr&sV@Ka2ph)3jn)CK3=F06%+4CG<$;o&htnFZ!=g(0n4LMA4`}djk7m=n
z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU

delta 442
zcmX9)O-lk%6n)b;mb6f&NEbm;61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
zRthehQp<ioAq+%O48GjhrlO+Pox1Q2_nv#+{d#7P9J~e=HbTgQ&;mk;ijh-3kW;e(
z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
zcP&Nw(O;ogKlFmCBIg5bq<OffWLb~o2jr#sf=_+23&RMToIQfL9{47AKyeO;1a)>J
zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$&ORN
mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
index e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b776258205e1d5 100644
GIT binary patch
delta 421
zcmaFDe1%zP0uUG;&}9%{V6bIiVEA8TJW)uczPUn$q4ZSeVde;h(!;MgckBm(&ZDpY
zbsl}`&d9)Ec)Rmn=Zm!NSOdlzMb@vG9g56a50n@+A7C%iRr%2sA^z>KLdmOc50S=)
z|NsAI;5=D!m+@c;Q_=N?3L)lFw%6jV2TIvGPrN>5c%buG>$g&-l7BD10Br{v65o74
z!m|EEaYRD}vp|V7kQ6F0>XvAH3^E94n?v&f<|1pAKd)~$A7DvqwD658)#cwFVZ(U1
z(K^7DfuU5M*;(VYJW#Upa9X2vSX3z=volBY0S*4`(QKMGUbF51+Qaa&258)`-3%Z4
zZtt%9ub0NpD4w=MnSsH9U+F;FtJKNSjMDY5-6qI0OaQ6_1rZE@G=l)pF$@fo&qL_h
zFuI>%zf-_#uKkVyuUXSNkGy7j{quG6%Zz{j|G(S<Bsw4be+DxMO257gVSvmG3vpwZ
NFyZwchzJ{m0sv1?z^?!R

literal 484
zcmX9*OG_g`5Uz2YXi!K{AwfI@4Wb8^4I;k92Z}6+5k#W02QLkK9j9Rq9_&L7ZDbtq
zqIePigaaNjIzCSdixLS)RFt&2cybqA?5!~cU5~H6s_N>tZQD+`9S{Z>1OTb`GBa#G
zt*_G(GaClinx^RkGo#yGe2LyNvnlO${H9mTj3XK78TZswjJl#0BPWZ(PsE3m63x5<
zkjV2pUL={H-<6y`Ayi}y>qBYR=+mmu*E{2X*HV!;FJ=@olMU=1D<ODc<ds9CLcd-$
z>r@&PjmS*9G|11z5fTzEKTW^U3gc6Jd}Rz>i=xwezWi&|RKrFLb)7MgiLyt(A5Nap
z{K@){_&;%jkXDHiVLej|v^%t)8c;mepB%?^+SRc((Td402KNZ-pIe~y>R7ebhG=Mi
zG0>h98oCZ15CogOAHb`XKiHDrNJxngrv+CGHM`_x1(RWLh67mGTp&(0SUJnJ3Rcm&
z65UvCM_?B@w(a-w1uqM*d0DnQmyjJzmTIyi$x?vuV|+aEM~V$8raq+<d#HFpKI8Y<
TrM$1pedcB-0FmP|Qr7<gpRvyd

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
index 6dfa68eabb48a44bc50a0b7fe678f80b5cdadfd5..6503a988abdac06f9aa88f0a65f2525e12233b0a 100644
GIT binary patch
delta 426
zcmeyu_JnPMtN<&s;Q?I+0R{$J1_p-zMaC0#Rrs4LR2WK6bslDpP$)h8+H+!>JIm{T
zoku68$xYtMs2t$H#K2&9yYpV>i?r@o1I8OgcCVQoiY!|Xl$bUjU@tOI`Oy_2{_U_r
z$*XP;k;aGr|Nm#;JXvy=@n8v4(e;K3A?8xfm(zi^wH_#C>pb!L_+($k?)of7kU&X%
z^8pFV6U7k?70d!9(m+zE#Hd@M@iE8{piK_V2bhbjRsOub-F$#0t<l0as#KSMdxQ<+
z;YRBKR|bYsd1hyg*YZHg&ckVq)?rble9X=q%?C92w@0&S-gwQr186V9%Rm4A|KIhO
z`OON2k{`Q%FmEt?H#v*RP`Ks4UK&56c-jtS1_lRyr2}cNv?s4)imrd{GC`hU0?-K)
zzyM?f2mqbLz%cndgq{tf`x*8-1-$0n?-=l!Bdznu%Ljj6Grj)ylK211_kaHXf4Teb
e|Nos2{y&2l1two#MwlBG;>Ivx!s|Uq(h~riBD@{|

delta 425
zcmaFD_JwVNtbi=D;Q?I+0R{$J1_p-zMV1qFRYV&rRDc|Y(&L?nnIjZR54`jN@+Ky@
zv%mcP|NsBaqZ1S4CZ1G|2xMYlFudJ)uk%G(cdP;9jUu;~%s_<>MRu(RN~~Dff$Sn<
zl^<OZ;@=J{l)UKn5NUh})X%_qvg9`7!4jsTs|^)G%%z+!X8~2V9w_DPJn`}nP{Cvy
z#_sxJMvz!Z5vv4H((*)cW<v$DK#2m76e_XlmS}toG6`sBAS=kuA}^IcFRuZGSXqF)
zv_=cxs8VzO?GZMNha0T}T!DVkWOmkgsRon;tLQwO)@U6TRVvKv%)zPw6y@I@&8B(d
zB`c7*1Be-zUOt;_%H$+G>%U$aKcjfs4rQRn_>~T%y|SO&#T1?W(j2HroM8dT6;J?X
zO+L>6re~jL*zXkZns2{jz-!L5&Lb~R`~e2e%P;?5ivNFk_0RwRFIW8q2IYhQ&nCRS
WJpl|r#)O5qF-(~7`Upe>LIMEmI;Oe+

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.port80.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.port80.raw
index 6c0bcc47ebff84830b59047790c70d96e9488296..0e53a574fab74db6973d7ea41a6a495266a4d0ae 100644
GIT binary patch
literal 28676
zcmeI*`@iM)RoC&AhK2&t38m6#D@l_eMJzNyu#grOl$OXfa;c#Re7Fq?-biQcc!M>B
z0MnLqpei@Tk5z7pGAP<W)h<X=OGPQ55UAjS(Ae~-G@un~>A2H8;eP=3=kb{H+-GK9
z-+lIbe)vB2JRWoA;>C*>Z`hYF$MGB&I4*Ep;JCnXf#U+l1&#|G7dS3(T;RCCae?Ck
zzo!?t;nJh;|8Ho%fph$Of#1`A@W&T-T;RCCae?Ck#|4fH92Yn)a9rTHz;S`&0>7^o
zc)+WDAg+7YqX#0nSlnz5<BCTf9C{`fi<`}1JVwvtVsW!Mj4Sm_E*3YN!+1A6lZ(a8
z<}e<sXL7N)*&N1IdL|c(o6TXoyPnC#;%0LgkJB@`Slnz5<303DE*3YN!+1|UlZ(a8
z<}lt%&*WlpvpI}Epl5QixY-=Wd+V88EN(W3@pwIxi^a|6Fiz>2Tr6%jhjF!@$;IMk
za~SWVXL7N)*&N0b^h_=mH=DzFUp<qH#m(k0o~UPXvAEeB#vjx(xmet64&(jwOfD8T
zo5OgLp2@}HW^)+V=$TwBZZ?PUhxAM?7B`#2_``Z87mJ(CVLVyS<YIBNIgF?1nOrPx
zHiz*?^h_=mH=DzFe?60n#m(k0uGKTSSlnz5<2pT)i^a|6FrFHRbGZLAxmet64&!<~
zlZ(a8<}hy1Gr3sYY!2f_J(G*Y&E_yZK+oi2akDv$KdNVPvAEeB#s}(|Tr6%jhw(H$
zlZ(a8<}f};&*WlpvpI}Ere|`oxY-=W2kV(!EN(W3@yGQ{E*3YN!+5%$$;IMka~L0@
zXL7N)*&N1)>X}?DZZ?PU3_X*J#m(k0ZqhTkSlnz5<7PdRi^a|6Fg{Gr<YIBNIgCG{
zXL7N)*&N1)>zQ0EZZ?PU5qc&Ui<`}1{7F5Ni^a|6FrKMra<RDC9L7iLnOrPxHiz+1
zdL|c(o6TX|qGxikxY-=Wv-C_Z7B`#2c($I&#o}gj7$2=?a<RDC9LC4!nOrPxHiwaV
zCKrpF&0&0O9M0kX&*WlpvpI~9(=)kP+-wfxIeI1+i<`}1e7v5?#o}gj7|+!+xmet6
z4&!-xCKrpF&0&0kp2@}HW^)*~>X}?DZZ?PUr}RuN7B`#2_(VOEi^a|6Fg{7o<YIBN
zIgC%%Gr3sYY!2g7^h_=mH=D!wR6Uc6#m(k0K26W$VsW!MjN9}~E*3YN!}!yBCKrpF
z&0&1Hp2@}HW^)*yp=WZjxY-=WXX=?;EN(W3@mYE%7mJ(CVLV^Y<YIBNIgCG}XL7N)
z*&N30dL|c(o6TW-ww}qw;%0LgFVHi&Slnz5<8$;(E*3YN!}zm$CKrpF&0&15p2@}H
zW^)*yr)P4pxY-=W=j)kVEN(W3vGhzX7B`#2_<}f`!~LJh#o}gj7+<Joa<RDC9L5*v
znOrPxHiz-WdL|c(o6TW-iJr;D;%0Lgr}a!O7B`#2_)<NSi^a|6F#epL$;IMka~OYK
z&*WlpvpI|}(=)kP+-wfx%k@ky7B`#2_zQX_7mJ(CVf;lslZ(a8<}m(}p2@}HW^)*S
zS<mERakDv$zoKVyvAEeB##iW>Tr6%jhjE9V$;IMka~LnwGr3sYY!2g$p2@}HW^)*4
z^-L}nH=D!wt9m9Ei<`}1yhzXFVsW!MjB|P>7mJ(CVf-~clZ(a8<}m)cp2@}HW^)*S
zL(k-5akDv$zo}<(vAEeB#^2I2xmet64&y8JOfD8To5T1jJ(G*Y&E_yl&*WlpvpJ0O
zaX1gebxbZ6H=D!wYCV&S#m(k0?$k56Slnz5<7@OxE*3YN!?;V&<YIBNIgGE>Gr3sY
zY!2h=^h_=mH=D!wdOeei#m(k0F6fzDEN(W3@nSubi^a|6FkYf(a<RDC9L7uaOfD8T
zo5T19J(G*Y&E_!f)-$<S+-wfxWqKwTi<`}1T+}nUSlnz5;~Vu%E*3YN!}umWlZ(a8
z<}hBaXL7N)*&N2-)-$<S+-wfx@93FaEN(W3@ptu1E*3YN!}w-BlZ(a8<}kiR&*Wlp
zvpI}!)ib$R+-wfx+w@E>7B`#2_;x*$i^a|6F#evN$;IMka~OYL&*WlpvpJ0K&@;JM
z+-wfxALyA}EN(W3vGq(Y7B`#2_=j;ghx<R1i^a|6FkYc&a<RDC9L7J=Gr3sYY!2fe
z>zQ0EZZ?PUoq8r0i<`}1e3zcd#o}gj7~idDa<RDC9LD$PnOrPxHiz-OdL|c(o6TYT
z6FrlQ#m(k0{;8hH#o}gj7~iL7a<RDC9L7J>Gr3sYY!2g}>zQ0EZZ?PU{dy)Bi<`}1
zT+%bSSlnz5;|KIiE*3YN!}u3^CKrpF&0+jYJ(G*Y&E_zEP|xIIakDv$f2C(~vAEeB
z#=q7xxmet64&#-2CKrpF&0*Z5XL7N)*&N0X>6u(CZZ?PU!+Itci<`}1yh_jHVsW!M
zjDMqNa<RDC9LB%ZGr3sYY!2h!>6u(CZZ?PUYCV&S#m(k0TF>NSakDv$ABn>`-2a(e
zEN(W3@uPYs7mJ(CVce@{a<RDC9L8((OfD8To5Q$I&*WlpvpI~{>X}?DZZ?PU@AXVB
z7B`#2c%7cf#o}gj7(b?Ga<RDC9LDSQOfD8To5T1IdL|c(o6TYTxSq+y;%0Lg|54B6
zVsW!MjQ^x(a<RDC9L7)RnOrPxHiz*BJ(G*Y&E_zEQqSaKakDv$pVBkASlnz5<EQmZ
zE*3YN!}!m7CKrpF&0+i(J(G*Y&E_zEM$hD8akDv$pVc$DSlnz5<9<Dpi^a|6Fn&(Y
z<YIBNIgFpzGr3sYY!2g%dL|c(o6TYTS3Q%9#m(k0enHRVVsW!Mj9=6<xmet64&%S+
znOrPxHit2KCKrpF&0+jf9M0kX&*WlpvpI}k)-$<S+-wdHPyOigGr3sYY!2gB^h_=m
zH=DzFlb*@N;%0Lg59*m*EN(W3@!$1KE*3YN!+5iv$;IMka~KclnOrPxHiz*RJ(G*Y
z&E_yp^h_=mH=D!wA9^Mii<`}1{7*fTi^a|6F#eaG$;IMka~Qv>XL7N)*&N1O^-L}n
zH=DzFSkL5QakDv$U(++WSlnz5<Ja{}E*3YN!}#BNCKrpF&0+i>J(G*Y&E_!Pre|`o
zxY-=W|J5_OSlnz5<2Uq7E*3YN!}v`-lZ(a8<}lu_XL7N)*&N3I(=)kP+-wfx9eO4g
zi<`}1{Fa`{#o}gj81K|Gxmet64&$<($;IMkbKd1mhkuTAb;Pp|*SLJghn+un^|?2_
z^rdG{&YyeYvtRs_Pdod|=g(d9tsj2j3(o%B`EyUX>)xmT^w~GudG5wI`}zy_UU~a<
zXYW0E?@N~+tb1O4I2Z0adFO@uF8#oR_0YFm5pmNSFZ|+#H=lmV=RV_#`|r5r<jTC`
zBkt-mH{aRse#g^q{EZji{-n3vd)=A0yyVs=p8uuGhi^6b9zS;G7q0k`Gmp9BXY1S(
zt~`6y$+dU&*{d$R?&S41^@Z2o^|rHDU3%+-b>^Ly9zI<E*@x>NF829%_B9{*x)<JF
z=dQf^%##lvpK#{pmt1rHfk&=)c+$MHue{@y8{cvA#yk7nPM?3~r@Y|o(@(wf_Gevj
z@A+G9dv3(pYp;CH(@w5E{NjasPoKZ#`7b#8_$#0DxI6o4r(XFvSAEd^Cy%}7kzpS?
zbGY2eO{cD#Q$PIX$DX==eyAe))Xj&_9(U>)r>^V6gKJM+-*36?;men=iA!I6`1)RP
z=<bP&moJ~X{{EBuF1_D__4ZfATkn43t6uT&hnzlj#gk6ob3;TPqSJ5r+Cz19+>=*D
z9Ik!o<_GKaJ&%jK@4vh6p1a?C_Zv<=@dM-1;rAT=tA=--N4}&-&bz)l<I8{IQNR7S
z{eGXnEMEO_x1GG_t3UR(lgFOE@S2myoc!iPFS`8Dsdrw!{LmLY^5KIIFY2DdkIT0{
z^|iM?^}bu5`kGrW%;g6!UVQZG$B)Majtd+YI4*Ep;JCnXf#U+l1&#|G7dS5PyKRAo
b-v03Kyl;H|XFe}3UVP|*M}Owg_mlr0pwq8e

literal 28676
zcmeI*_qU~IRlxBbLjs685mBO|gop|%NU?wvx1boY0V*O`9^2Sk%;?zns8I(n#xB;!
z-gT@5QP~<mte{w;Shg)@hy_KlGoB<L*YZzL*Ll{O^Evn2_j}Hn=e~EpYwrATufP8K
z>t7jntXIYrx8HeXBo~XD&0$=0+nqzt<YIBNIgHoPGr3sYY!2gMJ(G*Y&E_!fq-S!m
zxY-=WC3+?oi<`}1T&ibsvAEeB#+~&{E*3YN!?=r{$;IMka~OBkGr3sYY!2f!^-L}n
zH=Dz_o1V$V;%0Lgucc>lvAEeB#%t@DTr6%jhw(akCKrpF&0(C-Gr3sYY!2fxJ(G*Y
z&E_y(SI^{PakDv$yX%=;EN(W3@p^hD7mJ(CVcbK{<YIBNIgHoWGr3sYY!2fM^h_=m
zH=Dz_r=H2h;%0Lgm+P5aEN(W3@rHUP7mJ(CVZ4!^$;IMka~N-|XL7N)*&N2b^h_=m
zH=DzF6FrlQ#m(k0-c--zVsW!MjC<>uTr6%jhjE3T$;IMka~SuD!#Z65nOrPxHivPg
zp2@}HW^)*Cre|`oxY-=Wef3N(7B`#2cym3Ii^a|6Fy2DX<YIBNIgGc|Gr3sYY!2go
zdL|c(o6TX|U(e)XakDv$x6(7YSlnz5<E`~fE*3YN!+0A#lZ(a8<}e<hXL7N)*&N0L
z^-L}nH=DzFTRoGD#m(k09;9b-vAEeB#)I`tE*3YN!+40E$;IMka~KcRGr3sYY!2h?
z^h_=mH=DzFdp(nj#m(k0-a*ggVsW!MjCa&Cxmet64&z~ZCKrpF&0#!T&*WlpvpI}+
z(lfbO+-wfx5qc&Ui<`}1JW|i(VsW!Mj7RC2Tr6%jhw*4VlZ(a8<}lt_&*WlpvpI~^
zGr3sYY!2gH;;;_ae<l};o6TW7M$hD8akDv$$Lg6}EN(W3@veF%7mJ(CVZ583$;IMk
za~O})Gr3sYY!2hy^-L}nH=Dz_O3&nCakDv$_s}!BSlnz5<MDbX7mJ(CVZ5iF$;IMk
za~SWXXL7N)*&N1u>zQ0EZZ?PUK6)k>i<`}1ysw_g#o}gj7*EhMxmet64&#Y>CKrpF
z&0#!A&*WlpvpJ0S(=)kP+-wfx{q;;P7B`#2_y9eVi^a|6FrKVua<RDC9L5LgnOrPx
zHiz*PJ(G*Y&E_yZNYCVAakDv$r|OwpEN(W3@iaY?i^a|6Fg{q%<YIBNIgAg{Gr3sY
zY!2f?^-L}nH=D!wFg=rt#m(k0mY&JQ;%0LgA0CHwxc)P_Slnz5<0JG;E*3YN!}v%&
zlZ(a8<}f}=&*WlpvpI~9)-$<S+-wfxq@Kye;%0LgAERe-vAEeB#>eWJTr6%jhw*WG
zCKrpF&0&1Jp2@}HW^)*ypl5QixY-=WC+eA8EN(W3@kx3n7mJ(CVSKWl$;IMka~PkZ
zXL7N)*&N2F>X}?DZZ?PUX?i9Xi<`}1T&-tvvAEeB#;5C<Tr6%jhjERb$;IMka~P-e
zOfD8To5T1FJ(G*Y&E_yZQ_tjLakDv$(|RTsi<`}1e3qWc#o}gj7@w_Ya<RDC9LDG9
znOrPxHiz-KdL|c(o6TW-o}S6Y;%0LgpRZ?fvAEeB#uw<BTr6%jhf#Va7mJ(CVVsG>
zI$ZymTr6%jhw+7aCKrpF&0&0zp2@}HW^)){tY>nuxY-=WwR$EOi<`}1e2JdP#o}gj
z7+<Pqa<RDC9LAUFnOrPxHivOm&*WlpvpI~X>zQ0EZZ?PU3_X*J#m(k0o~dVYvAEeB
z#+U1vTr6%jhjE>r$;IMka~NNtXL7N)*&N38dL|c(o6TW-rJl*f;%0LgU!`YqvAEeB
z##if^Tr6%jhw(LfCKrpF&0&14p2@}HW^)){r)P4pxY-=W*Xx;FEN(W3@eO(=7mJ(C
zVLVIE<YIBNIgD@AGr3sYY!2g_^h_=mH=D!wW<8UO#m(k0zD3XEVsW!MjBnL5xmet6
z4&&SOOfD8To5R?8CKrpF&0&0d9M<9b&*WlpvpJ0K&@;JM+-wfxJM~O17B`#2_%1z@
zi^a|6Fuq&Q<YIBNIgIboGr3sYY!2gl^-L}nH=D!wK0T9*#m(k0zF*JeVsW!Mj33Z5
zxmet64&w*)OfD8To5T1aJ(G*Y&E_zESkL5QakDv$AJH?pSlnz5<45&OE*3YN!#JmB
za<RDC9LA67nOrPxHiz-!dL|c(o6TYTgr3R8;%0LgKdEPOvAEeB#!u;)Tr6%jhw;;T
zCKrpF&0#!S&*WlpvpI|#^h_=mH=DzFj-JWI;%0LgKci=IvAEeB#&h*dE*3YN!}wV}
zlZ(a8<}iLv&*WlpvpI~P*E6|T+-wfxd3q)ni<`}1w4TYu;%0LgzYvFYxc)P_Slnz5
z;}`WzE*3YN!?;n;<YIBNIgID)nOrPxHiz*7J(G*Y&E_y(sAqDqxY-=WFX@?FEN(W3
z@ghBwi^a|6Fn(Fj<YIBNIgDS?Gr3sYY!2gB^-L}nH=D!wH9eDy#m(k0eqGPxVsW!M
zjNi~Rxmet64&%joCKrpF&0)Mm&*WlpvpJ04)HAtQ+-wfxxAaUd7B`#2c&VPr#o}gj
z7{9G&a<RDC9LDeHnOrPxHiz-MdL|c(o6TYTo}S6Y;%0LgH|d#NEN(W3@%wrv7mJ(C
zVf=xf$;IMka~LnvGr3sYY!2fO^-L}nH=D!wBR!Lg#m(k0{#eiCVsW!Mj6cycxmet6
z4rBC8E*3YN!}!xUti$!6$;IMka~OZ7XL7N)*&N27>zQ0EZZ?PU7kVZai<`}1{H31B
z#o}gj7&q&gTr6%jhw)c>CKrpF&0*Z4XL7N)*&N1sJ(G*Y&E_y(u4i(wxY-=Wt$HRG
zi<`}1{I#CR#o}gj7=NQ@a<RDC9LC@3nOrPxHiz+ddL|c(o6TXoLeJ!4akDv$zt=Ol
zSlnz5;~(@)E*3YN!^7w~ti$|aa<RDC9L7KDnOrPxHiz*~dL|c(o6TXoO3&nCakDv$
zf7Ua(Slnz5<6rblE*3YN!}wP{lZ(a8<}m(E&*WlpvpI}^*E6|T+-wfxKlDs47B`#2
z_)k5Pi^a|6FkY=^a<RDC9L5DblZ(a8=G^W>ufK4Io9Ea^Z`;?09{1sn^W(S=$9*_{
zKOE=5aSj~kz;O;7=fH6e9OuAs4jkveaSr_7o&zuO@BE{8d>xPbaNLL6u4~8h;CLP!
z&x7Ol!Ep{8=fH6e9OuAs4jkveaSj~k!2h#3aQGDf$93F+;|?5m;J5?F9XRg5aR-h&
zaNL384jgyjxC8$Sci_Q?UmtN<#G?*Binws~!_S<)?DStg^O>h^J#+dVk9zvO-uKj>
zojHB^v)=yfhoAcWGpFx$?Trt3>8Y2TIep*5!Ex%B&fa+OQ?5AG=MQ<DJ9l&4@Vvu1
z`-1cTe&ND}voARJV>j3N@4qPG!7n@e$7gRj`HT;F&_y?0{kZcNACAteAAN0K^G=uC
z`EdX0hu-&Jp8k}3zUsy+uDRtISKZ^xpC0PC>n~sPvWtG<n%B7cck1-rFFtkG^H&~@
zytYr>_3Vqz|Kj0*2lv?*Ui+$3m!5mY&2`PI&;9-3r5<~Dsl$_AeaYpALm&R4Pye_&
zeeq@2TyeO)`!$bz#^q=J{I=&kyn`oRa@#w&`tkSukMqBKc<7Ql9X>jF=3(#s)Kl+x
z;@MAm<V820dBhXm?eN#T|HY5J-}$#VeDd}q&fa+P%p;!s)Kjl_@ni3D$^8zGo_O}t
zF1`Ov=Px<jz2WdD&VT6P$!>_baN)$2H=Vd*PW;R*mz=nAo>LKh;vt8R?sDQmC$8wj
zoqM0SvS0py!_k+=xsN)$@vk`4=icDv`nTuCE3SLlb5CD*;K>sg-SgxPZ+6(H!=Wc%
z{y~RhFN+)U(!;A>Ip-d7bDg~5E^*yW*Y$OC-7VL><ou%#&v5Uk!(rE7f4F=5y8VCQ
zzxu^-yWjNR{%Ab!F;BSlZqIv{C)|4J$+OQtd@;`d^M&(u;ru`S=Y<RBpY-a(&BG2)
zbJY!po7;apch!Afc-4JgaMgXDf7RK!aP#5(z4gXBPU72M<jL><xHvrWL;v%%{x6Nr
BvabLD

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.raw
index a78d5b407c8a106c221af127216d073cf8fdb99d..865846da42a45c16b69746f16963d47a6c6e71b0 100644
GIT binary patch
literal 28676
zcmeI*_qU~YRmbriA`xs85hW^0AgEZPfZc#@MKpG77_ohAV{b8|qoVFHMjgO7_O4%h
z?}aETTLTE#ut%|MjfLUbuwZ9ANnWny-+<>?YtHN3d+z%=b3XTnXPvv&+_`Y!!i8)0
zrAu)<jtd+YI4*Ep;JCnXf#U+l1&#|G7dS3(T;RCCae<fW1+Mwgd*1(F(|jK1_;Z1m
z>Tmq<#T^$oE^u7nxWI9N;{wM8jtd+YI4*Ep;JCp5s|D`#YVVAz@4k0uBo~XD&0$=2
z*PTPp<YIBNIgEShnOrPxHivP!p2@}HW^))Xqi1rlxY-=Wz4c5k7B`#2xI)k5VsW!M
zjF;6jxmet64&y$0CKrpF&0*YE&*WlpvpI~H(=)kP+-wfx<@HQ17B`#2cm+L^i^a|6
zFkVs5<YIBNIgD4*Gr3sYY!2g;p2@}HW^))<>X}?DZZ?PU%6cXji<`}1+)vNsVsW!M
zj91Y!xmet64&(lMCKrpF&0)N%p2@}HW^)*?re|`oxY-=W1N2NT7B`#2xJu9DVsW!M
zj91q)xmet64&ycSOfD8To5OfbJ(G*Y&E_y3sAqDqxY-=WYw4L>EN(W3@!EPO7mJ(C
zVLV9B<YIBNIgG3IOfD8To5Of;9FD{FpUK7IW^))1(KESN+-wfx8a<PX#m(k09;#<@
zvAEeB#_Q;rTr6%jhw-|4CKrpF&0)Nrp2@}HW^))1(=)kP+-wfx_4Q0H7B`#2cmq9?
zi^a|6Fy2tl<YIBNIgB^bGr3sYY!2gEJ(G*Y&E_!PSkL5QakDv$H_<b>Slnz5<KcQH
z7mJ(CVLU?5<YIBNIgCf@nOrPxHiz-1dL|c(o6TXonV!kT;%0LgZ?0!@vAEeB##`u_
zTr6%jhw+wrCKrpF&0)Nip2@}HW^)*Ct!HwvxY-=W+vu5GEN(W3ah;yY#o}gj7?093
zxmet64&%{!CKrpF&0)N)p2@}HW^)*Cr)P4pxY-;=>X}?DZZ?PU_Hj54*MBA#i<`}1
zyn~*}#o}gj7?062xmet64&xp5OfD8To5Oglp2@}HW^)+tq-S!mxY-=WJL{QTEN(W3
zalM|&#o}gj81JHIa<RDC9LBrqnOrPxHiz+UdL|c(o6TXoyPnC#;%0Lg@1bXMvAEeB
z#(V0STr6%jhw)x|CKrpF&0#!F&*WlpvpJ0S)-$<S+-wfxee_H&7B`#2cwaq}i^a|6
zFy2qk<YIBNIgIz$Gr3sYY!2h`dL|c(o6TW-fS$?4;%0LgH|UvMEN(W3@qv0K7mJ(C
zVLU<4<YIBNIgAg|Gr3sYY!2gt^-L}nH=D!w5IvKN#m(k0K2*=-VsW!Mj1SW@xmet6
z4rA$=Tr6%jhw<TYI1bl;CKrpF&0&0mp2@}HW^))Hsb_MrxY-=WN9mbdEN(W3@zHuF
z7mJ(CVVu@8xmet64&!6=OfD8To5T26J(G*Y&E_yZPS50GakDv$kJmG~Slnz5;}i5u
zE*3YN!}vr!lZ(a8<}f}<&*WlpvpI}U)-$<S+-wfxQ}j$O7B`#2_*6ZUi^a|6Fg{Js
z<YIBNIgA_iOfD8To5T2YJ(G*Y&E_y}(lfbO+-wfxjGoEG;%0LgpP^@RvAEeB#%Jo8
zTr6%jhjCWV<YIBNIgHQJGr3sYY!2hI^-L}nH=D!w96ghZ#m(k0o~UPXvAEeB#^>sp
zTr6%jhw*uOCKrpF&0&1Lp2@}HW^)*&XL7N)*&N2XI2?Dz)l4oHH=D!w0zH$9#m(k0
zZq_roSlnz5;|ujnE*3YN!?;Dy<YIBNIgBsTGr3sYY!2g#^-L}nH=D!w5<QcP#m(k0
z&g+?6EN(W3@gzNyi^a|6FrKVua<RDC9L7`hOfD8To5T20J(G*Y&E_y})ib$R+-wfx
z%k)ex7B`#2xS(fpvAEeB#+U1vTr6%jhw&A9CKrpF&0&0{p2@}HW^)){rDt-nxY-=W
zSL>NvEN(W3@ilrT7mJ(CVSKHg$;IMka~NNzXL7N)*&N2#>zQ0EZZ?PU4SFUQi<`}1
ze50Pp#o}gj7~iC4a<RDC9L6{6nOrPxHiz*odL|c(o6TW-tDecl;%0LgThHWTakDv$
zZ;Qimxc)P_Slnz5<J<L2E*3YN!}tz8lZ(a8<}kif&*WlpvpJ0K(lfbO+-wfxyY);i
z7B`#2_#Qozi^a|6FuqsM<YIBNIgIbqGr3sYY!2i5^-L}nH=D!w0X>t8#m(k0eo)Wk
zVsW!Mj33f7xmet64&#UQOfD8To5T1KJ(G*Y&E_zERL|sMakDv$AJa3rSlnz5<Hz+(
zE*3YN!}tk3lZ(a8<}iLz&*WlpvpI~P(lfbO+-wfxr}a!O7B`#2c&eVs#o}gj7`N$}
zTr6%jhw(FdCKrpF&0+kkp2@}HW^))%(=)kP+-wfx=k!c27B`#2_<22(i^a|6Fn&SL
z<YIBNIgF?4nOrPxHiyxACKrpF&0+jv9FD{FpUK7IW^)+7q-S!mxY-=W?Rq8`i<`}1
zJVVdqVsW!MjA!bZTr6%jhw&^ulZ(a8<}iL)&*WlpvpI}s>zQ0EZZ?PU96ghZ#m(k0
zo~vhavAEeB#;@p^Tr6%jhw-a=CKrpF&0+kSp2@}HW^)+7u4i(wxY-=WZ|Ip^EN(W3
z@jN|~i^a|6Fn&|d<YIBNIgH=ZGr3sYY!2hM^-L}nH=D!w9X*qa#m(k0epk=rVsW!M
zjNj8Uxmet64&(RrOfD8To5Q$6&*WlpvpI}E&@;JM+-wfx5A{qg7B`#2c)p&=#o}gj
z7=NT^a<RDC9L68(nOrPxHiz*idL|c(o6TYTsh-Kj;%0Lgqi1rlxY-=WpT*%gT>qI|
zEN(W3@#lIb7mJ(C;o+(8d447ri<`}1{Dq#$#o}gj7=Ni}a<RDC9L8VinOrPxHiz-o
zdL|c(o6TXoK+oi2akDv$i+Uy(i<`}1yim{NVsW!Mj1xVRi^a|6F#bl*<YIBNIgG#6
zGr3sYY!2h^^h_=mH=D!wdp(nj#m(k0{z1>=VsW!Mj2G#dTr6%jhw+bkCKrpF&0+kL
zp2@}HW^)+-tY>nuxY-=Wzv!7<EN(W3@nSubi^a|6F#c7~<YIBNIgEePGr3sYY!2h!
z^-L}nH=D!w4?UBM#m(k0{!`E7VsW!MjQ`Rzxmet64&%S|OfD8To5OgCp2@}HW^)*q
z^h_=mH=A>}k2w5uq$?vHeK^OZ8{hQY*(=Zf<x`$==H%Sj`#<_g4}7mPe}3-lRbT(+
z=Rf?+ADlb;z*}y=_P5VG@8+`)jWf?ZfBWS(Tz%&Dll$KG^uuxfnI|tf|ICY@e_6yM
zo`3#N&cERFlRxC)m)&vWbtjkSjc;*F-}K0v`(<yu_M!jwq#GXa;@hvj>4i_e{{H9w
z?9$;^4Bq!SH~sNtzj)KVZv6c^d%w%iTygS%Tl&lu=bwG@+(-2JXWjDRGxxgbB^Tf5
zaNfg7KJ4bc>aCys={MBb%dfoYH4nG<yXlcnzUthacb(_(WO;L6e&cly{jZbf-`p>A
z`rKQ+#}m$6d+Mn-JnFLB&t3Pp$3~oa(B+SL*vW$q51zmM^ttOE|AaHIbopcMb8|oJ
z)Kfp`ir2s6<leX4HRQ!79!__1?WwEh)X%=)-lrZiKT{EX>XC<!?sMwlr>^e9od=zI
zNWU;&bm`Jnaq+7U&24ev(xp=mx#Q$H|M9f=hg+Zjv@d$m8=pRP*#l1Bc1=VczWDSD
zKl$+0SH^95Ma1Epr*FGY+<M2Yee2x%f?J<=^4Qml3x~%K{~g1HyZ#Dy9e4ls#jpI0
zd;G@#^+$aCW%2ZPc-+a$J^k$;cXIF3=bv$Muakd2`NE42f61jw7oT|7&7%&l;kLt{
zOV>a6S=T@Knb$w~8P}hmOMmr$&VSFd9B+>c92Yn)a9rTHz;S`&0>=f83mg|XE^u7n
irDcJOfB2%i-d5iIzVh+!_fB!)!o}O~`OMv)zVJWS51Etz

literal 28676
zcmeI*_qU~IRlxBb!cc4z0VOI*h=`z~ASxiBTM>*{07XO;eQaZIF{5MOqedOT7{y*6
z?7b^dRJH~XJN77+4YpijN3k=WBp=t(KS9@d*1G3&&YAan-kIl~yWchU{&26q{`%`*
z5x1{b#1*&Qc|{}_i<`}1TypE3L(k-5akDv$JLs8QEN(W3ajBlk#o}gj7<be&xmet6
z4&#)b$;IMka~OBhGr3sYY!2hjdL|c(o6TX|MbG47akDv$yXu)-EN(W3@oIV|7mJ(C
zVZ6GY$;IMka~Q9oXL7N)*&N1e>X}?DZZ?PUT6!iIi<`}1oYphBSlnz5<1#&yi^a|6
zFkV~F<YIBNIgGpMnOrPxHivO{J(G*Y&E_!fp=WZjxY-=W>*$$WEN(W3@w$2@7mJ(C
zVcb*C<YIBNIgHEoOfD8To5OfLJ(G*Y&E_y(U(e)XakDv$H_$V=Slnz5<6e3u7mJ(C
zVZ5Q9$;IMka~N-=XL7N)*&N2b^-L}nH=Dz_LeJ!4akDv$`@~@#uK!Ff7B`#2xKhvL
zVsW!Mj5pRZxmet64&%OhCKrpF&0)NWp2@}HW^)+#(=)kP+-wfxP4!GJ7B`#2xWAss
z#o}gj7!S}hxmet64&%-AOfD8To5Of>J(G*Y&E_!PLeJ!4akDv$2kMzzEN(W3@s@ff
z7mJ(CVZ4=|$;IMka~KcOGr3sYY!2hWdL|c(o6TXowVuhv;%0Lg579HZSlnz5<8Aaz
zE*3YN!+2XglZ(a8<}lt)&*WlpvpI~1>X}?DZZ?PUFg=rt#m(k09<FC{vAEeB#@p+e
zTr6%jhw%tKlZ(a8<}e<qXL7N)*&N2B^h_=mH=DzF2R)OE#m(k0-cirwVsW!MjMOu^
zSlnz5<DKHL4%dGs7mJ(CVZ5`R$;IMka~O}-Gr3sYY!2gH^h_=mH=DzFjGoEG;%0Lg
zkJU4|Slnz5<6ZSkE*3YN!?;S%<YIBNIgEGHGr3sYY!2gbdL|c(o6TXoyPnC#;%0Lg
z@1bXMvAEeB#(V0STr6%jhw)x|CKrpF&0#!V&*WlpvpI|>=$TwBZZ?PUL_L#>#m(k0
z-doS)VsW!MjQ7zqxmet64&zCBCKrpF&0)N+p2@}HW^))%)-$<S+-wfx{q#&O7B`#2
zc#59M#o}gj81JuVa<RDC9L7`iOfD8To5T13J(G*Y&E_yZP|xIIakDv$r|FqoEN(W3
z@j-ef7mJ(CVSKQj$;IMka~Mm{<YIBNIgAg9!#Z65nOrPxHiz+{dL|c(o6TW-n4ZbS
z;%0LgAFgL|vAEeB#z*LxTr6%jhjB*F<YIBNIgF3gGr3sYY!2h2^h_=mH=D!wXg!mQ
z#m(k0K1R>vVsW!MjE~hbxmet64&&qWOfD8To5T2cJ(G*Y&E_yZLC@r3akDv$Pt-HH
zSlnz5<CFAEE*3YN!}w%9lZ(a8<}j|-Gr3sYY!2g7^h_=mH=Dz_M$hD8akDv$vw9{M
zi<`}1e5#(w#o}gj7@wwRa<RDC9L704lZ(a8<}f~8&*WlpvpI~<&@;JM+-wfxGxba^
z7B`#2_$)n>i^a|6Fg{z)<YIBNIgHQIGr3sYY!2gd^-L}nH=DyKJ(G*Y&E_!9$6+0=
z|4c3xH=D!wJUx?(#m(k0K3~t|VsW!Mj4#kLxmet64&z!qlZ(a8<}kic&*WlpvpI|}
z(lfbO+-wfxi}g${7B`#2xS(fpvAEeB#?$poE*3YN!+3_C$;IMka~RLmGr3sYY!2f~
z^h_=mH=Dz_PS50GakDv$FV!=-Slnz5<9a=li^a|6FuqLB<YIBNIgBsYGr3sYY!2gD
zdL|c(o6TW-g`Ua9;%0LgU#VwuvAEeB##iZ?Tr6%jhw;^VCKrpF&0&0vp2@}HW^)){
zt7metxY-=W*XfyDEN(W3@%4Hp7mJ(CVSIz0$;IMka~R*KXL7N)*&N0<>6u(CZZ?PU
z&3Yymi<`}1Y(0~U#m(k0o*jpExc)P_Slnz5<6HDhE*3YN!}wM`lZ(a8<}kiZ&*Wlp
zvpI}!*E6|T+-wfxJM>I07B`#2_)a~Oi^a|6FuqIA<YIBNIgIbtGr3sYY!2gl^h_=m
zH=D!wUOkhG#m(k0zE98OVsW!MjPKVoxmet64&w*(OfD8To5T1)J(G*Y&E_zENYCVA
zakDv$AJ#LuSlnz5<45#NE*3YN!}w7>lZ(a8<}iLt&*WlpvpI|(*E6|T+-wfxC-h7%
z7B`#2c#fXQ#o}gj7&qvdTr6%jhw+noCKrpF&0+kMp2@}HW^)+N)ib$R+-wfxr}a!O
z7B`#2_!&Kui^a|6Fn(6g<YIBNIgID&nOrPxHiyxACKrpF&0+jp9M<9b&*WlpvpI~P
z*E6|T+-wfxMm>{@#m(k0p08(evAEeB#tZaJE*3YN!+4>d$;IMka~Qv%XL7N)*&N1;
z^h_=mH=D!wMLm;?#m(k0eo4>dVsW!Mj9=C>xmet64&zt!OfD8To5T23J(G*Y&E_zE
zP0!?FakDv$U)M9aSlnz5<HdR=7mJ(CVf==k$;IMka~Qv=XL7N)*&N1i>6u(CZZ?PU
z+j=G!i<`}1{EnW<#o}gj7{9A$a<RDC9LDeInOrPxHivPOp2@}HW^)+7uV-?xxY-=W
zALyA}EN(W3@e)0gi^a|6F#b@_<YIBNIgCHjGr3sYY!2g(^-L}nH=D!w6FrlQ#m(k0
zM$hD8akDv$m&RcouK!Ff7B`#2c$uEb#o}gj7=Nl~a<RDC9LAsNnOrPxHiz-&dL|c(
zo6TYTg`Ua9;%0Lgf2n73vAEeB#?5*r7mJ(CVVvlhTr6%jhw*YflZ(a8<}hy2Gr3sY
zY!2hE^h_=mH=D!wYdw>T#m(k0{zlK_VsW!MjK9@0xmet64&(3iOfD8To5T2fJ(G*Y
z&E_!vLC@r3akDu*jGn_f%pWEfi<`}1{G*=9#o}gj82_Yaa<RDC9L6j4OfD8To5T2L
zJ(G*Y&E_!vMbG47akDv$f7LU&Slnz5<KOg5E*3YN!}xbSlZ(a8<}m(4&*WlpvpJ0a
z)HAtQ+-wfxReB~Di<`}1T+}nUSln#RZ9e4si?_S^L+qos?(0L2`*8dF<G2sUeK>wS
z9OuDt4jkveaSj~kz;O;7=fH6e9OuAs4*cJq126Xf{G+#j9*_HQ+=pAQYsdG&@qKW7
z9~{39j&tBR2aa>#I0ue%;5Y}4bKp1!{-4c(!><51uHz0Ici^}K#~nECz;OqTJ8;~A
z;|?5m;J5?F9r!=60}np@I*H379(DNE#Ko&0e*WBL=l=Ye&pdm}`E&Pp)YI?v__HrN
zf9~?HecKBka`yMnpS#z!H$L#U&c68kx%(atj<dgT;l@j!a>dy`d5y!P8=iMq7hZ7k
z?-ws#Jn-yGA|Cvb3x9m!<}=TD+Ji2+>FURxTzWVvuYQMX`<k~ub?3wVs~>XTe|h>-
z?)l0auej#sXIyoU^DjM=ao1nG<|UW>+%<Q&`giKw-7Y<Q*OS*j9C>Y@z3YV+o&5aa
zfCu-57he0yvv;`WRVR-=oZ|3eSD(84aLB`7^eG=*=PteMnkx>scf011&$#^jpWga<
zhciF%)U9W}`f>ODkCWd$Jay`hhev15KkPl9diJ5GpYxPQUUK94M?B#%hkwokE`9X<
zPwsd4!`qIyaO0Wtk9hJ^&))sgN8jbt{SVKce$EHn=>a#LoI2dS;qVbBXAUoRL(IjC
zr?0%}^c8dZr*1xV`pWsqis;jCeRy=2(+@g*MIY|m`}CFl@&_J{zC2EzbtwPsx$$?`
zz2vzcckwOHoWA6qXKr}o!@e92IrH)-9*(&zZpb?w&UWRTx#2Ex-A&i^b#vX#*S+}U
zafkBWQHMkR_nYeQ^lj_5pTa-u*W)(7{=fafc-}id;g(l_-a9?vmOGuf@chFk;pCq$
zo_yBDlT)v{c=6<^x86ML@RC>EaJaec+jCdl=Y?0@=LJ{Y=lNG%n2UdLIMppT-hRGY
SPx9m^JvI){eBb~48~hhX6Rzk0

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.serial.raw b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.x64.serial.raw
index 61c71349a8a599916f3eeae8c5dee92efb56db71..f1d6536cec924d0e167cf1ee4e9309ed5fd7ad60 100644
GIT binary patch
literal 28676
zcmeI*d-SE}RnYOBPA_S-OsLgHTW#7@C}J^bX{DCprWFh*Pz6gYw+Gb08;W5D$18h`
z5vMI70*Z*>qj<q90WS@y+Kp*T!3$MXf)(5l!A=K9Y_$|f^Ycveajj->sei+H{y3lW
z{APXM^S=9>wcd4Rt@+J8_uO;O&HLmej_Wvq;{=WqI8NX=f#U>@6F5%bIDz8?juSXe
z;5dQf1b$Xe;O2WD{r-P*^X;7D-wXV#e&df9cbvd+0>=p)Cvcp=aRSE)94By`z;Ob{
z2^=Tzb7}$)x!Q-~rVl)OD3XiC&E_z!yZYqNGr3sYY!2gbdL|c(o6TXI(lfbO+-wfx
z@p>i~i<`}1JVDRoVsW!Mj3?@uTr6%jhw&smlZ(a8<}j|;Gr3sYY!2hedL|c(o6TW7
zMbG47akDv$pQmSXvAEeB#?RL?xmet64&$kMCKrpF&0&0qp2@}HW^)*)^-L}nH=Dz_
zLC@r3akDv$57jfdSlnz5<7s*(7mJ(CVf+F;lZ(a8<}jYFXL7N)*&N0%)HAtQ+-wfx
z7wMT?EN(W3@eDnai^a|6FmBW{xmet64&xW=nOrPxHiz*`^h_=mH=DzFrk=^g;%0Lg
z&(brwSlnz5<Cp50Tr6%jhw;nwOfD8To5Ogvp2@}HW^))f>6u(CZZ?PUoH(q*{h!Ij
z;%0Lg&($-zSlnz5<7PdRi^a|6FrKGpa<RDC9L6u#Gr3sYY!2hY^h_=mH=D!wa6OZY
z#m(k0p08(evAEeB#z*LxTr6%jhw&@)OfD8To5T1>J(G*Y&E_zErJl*f;%0LgFVHi&
zSlnz5<D>LUE*3YN!}wKtCKrpF&0*Z4XL7N)*&N2LdL|c(o6TXoP|xIIakDv$7wMT?
zEN(W3@zHuF7mJ(CVZ2z+<YIBNIgFR+nOrPxHiz-6^-L}nH=D!w7(J7V#m(k0UaDtu
zvAEeB#;?&cxmet64&!BdCKrpF&0&13p2@}HW^))X*E6|T+-wfx<Md1}7B`#2__cZ_
z7mJ(CVWghP#o}gj7#|;pb-4dCxmet64&xPiCKrpF&0)M!&*WlpvpI}kr)P4pxY-=W
zC+L}6EN(W3@rimS7mJ(CVf=bMlZ(a8<}hy4Gr3sYY!2g-^h_=mH=D!wWIdCM#m(k0
zeuJLL#o}gj7{5`^<YIBNIgC%yGr3sYY!2g7^-L}nH=D!wG(D4x#m(k0UZrPpvAEeB
z#&6Oyxmet64&yiLnOrPxHiz-)dL|c(o6TW-hMvjA;%0LgzeUgFVsW!Mj92TKTr6%j
zhw+(uCKrpF&0*ZGXL7N)*&N1i)ib$R+-wfxHF_o&i<`}1e3qWc#o}gj7@w_Ya<RDC
z9LDG9nOrPxHiz-KdL|c(o6TW-o}S6Y;%0LgOV8wDakDv$&yT}8-2a(eEN(W3@dbJ&
z7mJ(CVf;2dlZ(a8<}iM{p2@}HW^)+7L(k-5akDv$GkPW$i<`}1e4(Dn#o}gj7{61`
z<YIBNIgH<>XL7N)*&N32)-$<S+-wfx_vo2iEN(W3@q6`5E*3YN!}uaSlZ(a8<}iMr
zp2@}HW^)+7U(e)XakDv$FV-`;Slnz5;}7VWTr6%jhjE9V$;IMka~NNuXL7N)*&N1M
zJ(G*Y&E_!9>6u(CZZ?PUrFte8i<`}1{6RgFi^a|6FwX0lTr6%jhw+E>OfD8To5T3S
zdL|c(o6TYT5j~TO#m(k0{-~bG#o}gj7=KL9<YIBNIgCH9XL7N)*&N1~>6u(CZZ?Ne
zdL|c(o6TWdh{Jj)Zent=xY-=WpU^Y8Slnz5<4!%3i^a|6F#e>T$;IMka~OB&nOrPx
zHiz-2^h_=mH=D!way^ra#m(k0{<NOS#o}gj7#H<SE*3YN!+5Qp$;IMka~QAFGr3sY
zY!2h~dL|c(o6TW-g`Ua9;%0Lgck7v4EN(W3@s)Ze7mJ(CVcer<a<RDC9LAr~Gr3sY
zY!2hA^h_=mH=D!wYCV&S#m(k0zDCdFVsW!Mj6bVqa<RDC9LAs1Gr3sYY!2gV^-L}n
zH=D!w^Li#1i<`}1e4U=j#o}gj7=J;}<YIBNIgGE@Gr3sYY!2fu>X}?DZZ?PU4SFUQ
zi<`}1e50Pp#o}gj7=KC6<YIBNIgG7ma<RDC9L8Uc!#dpmnOrPxHiz+7^h_=mH=D!w
zCOwmj#m(k0{;HnI#o}gj7=KOA<YIBNIgG!qXL7N)*&N2-&@;JM+-wfxoApdC7B`#2
z_?vnr7mJ(CVf-yUlZ(a8<}m)Yp2@}HW^)*SN6+M9akDv$zpH0*vAEeB#^2L3xmet6
z4&z(&OfD8To5Q$Q&*WlpvpI}!)ib$R+-wfx+w@E>7B`#2`1^V$7mJ(CVf+I<lZ(a8
z<}m)Dp2@}HW^)+-NYCVAakDv$H|UvMEN(W3ai5;a#o}gj7~igEa<RDC9LD{6CKrpF
z&0)Mz&*WlpvpI}^tY>nuxY-=WKhZO}Slnz5<Dcr8Tr6%jhw&yolZ(a8<}g~%<YIBN
zIgIa!!#dpmnOrPxHiz-g^h_=mH=DzFK+oi2akDv$H|v>PEN(W3@fJOki^a|6Fy5+X
za<RDC9L9I*nOrPxHiz*xJ(G*Y&E_z^OV8wDakDv$@76Q9Slnz5<Dcu9Tr6%jhw(4;
zOfD8To5T2*dL|c(o6TYTD?O8o#m(k0zDLjGVsW!MjJNBVTr6%jhw-oVOfD8To5T1w
zdL|c(o6TW-ub#=p;%0Lg|5nfBVsW!MjDM$Ra<RDC9LB%bGr3sYY!2i5^h_=mH=DzF
zP|xIIakDv$@7FWASlnz5<3H$`Tr6%jhw%<QlZ(a8<}m)Fp2@}HW^))npl5QixY-=W
z59*m*EN(W3@t^ceE*3YN!x%l2i^a|6Fn%Zw>u~>Pa<RDC9L5jpnOrPxHiw6oe)RR3
zTr6%jhw-2FOfD8To5T1KJ(G*Y&E_zERL|sMakDv$|DtDdvAEeB#yj;)E*3YN!?>hp
za<RDC9LBr!OfD8To5Q%QXL7N)*&N1?>6u(CZZ?PUU-e8b7B`#2xT0rrvAEeB#(&c@
zxmet64&%r5OfD8To5T3;dL|c(o6TXoThHWTakDv$_vo2iEN(W3@jvuTE*3YN!}y<i
zCKrpF&0)M(&*WlpvpI~P&@;JM+-wfxeR?Jri<`}1{G^`A#o}gj7(b<Fa<RDC9L7)U
znOrPxHiz-Bp2@}HW^)+t*E6|T+-wfx5j~TO#m(k0PV`JJ7B`#o0q_6mQ}=%PmHU74
z)V*=#{`Z}__qr=rfAXX&m%ifEt%rZ9bVJ0;4~IXw<3$(F-*Em%UjO=YmoJ=u`paMY
ztWP`l!xzrq_;oM7`1$9)|HAoa-Sxl=zW3bQ?>zs!IQQKbA2@aUP3IoC{7Gl-fB&f;
z`{tX@{=}K9NB)8<kKNyL&Hky^?4NSwzBe7##kX93<l<W%n_hdUTdzrf=AkaV?Qs#e
zzT@H#UVP`7*L}_{*FAX0$6Y>^cf9njKKtT3`$>1)^1S!G_V#DI_ko+vzUy_jJ^jKD
zog9Aq;gi4X><?V`9cLeR$M@Cwr=2?Y<V#<Bn8aOu?ui%QcKJJR?Tc@{>%He*@z@hP
zbIpnTzpwG^Bmeg!{C`~9yRW-?T4z7+&c5-bZ~Kzl>-?!3&OY<-__VVxeBF%~9=dud
zhwIHd`_vsTd)~vB-*IO@{>+7s`IOh3d%@{9-2SoGJ#gV=ulj_DbI(5Y%I9Bx_TdjN
zK5*v3%U=DOb02c*mDk_d&p-W!&wAoVJb3vD_g(#%U3&PDlatF|bo!<_eg8Y3aQeCP
z?G@3dUwGJEfBKfwH}&Dkvrj*_-}SlgJ~_ED9(!#sxn?>aea-&=@U}hkaBcU+Jtrrp
zpZnnDi#|{9yZUju^~wkDUh<gTQy;T?%9WpbWBmBt?|9>9zvrXQoWAZEXYRW>A`d5d
z=3S3}&&kORabG?$;&3gGJ=+&ub9OJhX8$wK_RM|P$K4O!-FMI3@4Wl%mp}c(<BJc+
zKl~>fAGEFx@#^}(Z`b_l?|Ia(|KEO#{a41DUh%5SPkqzJzv}Y!XD+_^((Mmle%$5v
zUV7w_OJDf#$;qV`z5np=rH6OozQdb)a@%v>dfRi}a@%v>eA~r2`Oy!0t*cKTeYNA`
zaRSE)94By`z;Ob{2^=SIoWOAc#|ivgn82m`-}8ZQ1Xr*1)t~W+anC)MzUk4QJo-i9
Fe*tvrwzvQQ

literal 28676
zcmeI*eb}aXS<vxw85UR+XGMz5D3%osDvf0oMZiuWX+=>iBf_koT4VNV>r74W=UAH!
z&^G!0-me$S%5r;UT`EppK(rT8)0QYZ)ueq`n=A}bUdDTNKOVMYNA+(W_wP97`P|n%
z*Z01!>vvzz?>e5DKb}jME?s(OJUreRH$U{?osnEDZZ?N;-PH$&p2@}HW^)*i(lfbO
z+-wfxl%C1O;%0LgkJdA}Slnz5<9a=li^a|6Fdn04a<RDC9L8hyOfD8To5OgVp2@}H
zW^))f=$TwBZZ?PUcs-Mg#m(k0K0wdpVsW!Mj1SZ^xmet64&w=WCKrpF&0&0yp2@}H
zW^)*)^-L}nH=Dz_QP1RJakDv$57sleSlnz5<B57E7mJ(CVSI?5$;IMka~Mz3Gr3sY
zY!2g>=$TwBZZ?PUOZ7}H7B`#2c(R_!#o}gj7&qyeTr6%jhw;nwOfD8To5T1}J(G*Y
z&E_zExt__z;%0LgPth~ESlnz5<5%dJTr6%jhw&@*OfD8To5Ogjp2@}HW^))f>zQ0E
zZZ?PUv^b2z{h!Ij;%0Lgx9FK%EN(W3@nL!<7mJ(CVLV;W<YIBNIgAh2Gr3sYY!2fi
z^h_=mH=D!wReB~Di<`}1JVVdqVsW!MjA!bZTr6%jhw-cROfD8To5T1udL|c(o6TYT
zT0N7C#m(k0K2p!*VsW!MjE~YYxmet64&&G9nOrPxHiz*nJ(G*Y&E_y})ib$R+-wfx
z*?J}yi<`}1+@@!8vAEeB#z*U!Tr6%jhw(9bCKrpF&0#!8&*WlpvpI~9)ib$R+-wfx
z<Md1}7B`#2c&?tw#o}gj7$2`^a<RDC9LDqXOfD8To5Og%p2@}HW^))X&@;JM+-wfx
z6ZA|j7B`#2`1N`w7mJ(CVWghP#o}gj7@ru2ak&38xmet64&#M-CKrpF&0)Mq&*Wlp
zvpJ04pl5QixY-=WC+V47EN(W3@nSubi^a|6Fn*(+$;IMka~QYlnOrPxHiz-adL|c(
zo6TXoM9<`6akDv$Pth~ESlnz5<5TraE*3YN!+5El$;IMka~PkdXL7N)*&N2F>zQ0E
zZZ?PUGCh-v#m(k0K10vsVsW!MjNhbZa<RDC9L8_fGr3sYY!2fy^-L}nH=D!wEqW#w
zi<`}1yj;)ZVsW!MjNhtfa<RDC9L6j3OfD8To5T2RdL|c(o6TXoQqSaKakDv$&(brw
zSlnz5<G1UXTr6%jhw<5ZCKrpF&0+iwJ(G*Y&E_zEr=H2h;%0LgOV8wDakDv$&xyl0
z-2a(eEN(W3@ws{?7mJ(CVSJvR$;IMka~Qu%&*WlpvpJ04t!HwvxY-=W89kGW#m(k0
zK3~t|VsW!MjNhYYa<RDC9L5*unOrPxHiz+h^-L}nH=D!weR?Jri<`}1{C+)?i^a|6
zF#dp^$;IMka~OY6&*WlpvpI}Eq-S!mxY-=W7wVZ@EN(W3@rU(HE*3YN!?;7w<YIBN
zIgBsTGr3sYY!2hBp2@}HW^)+l^h_=mH=D!wBYGwmi<`}1{82rVi^a|6FwX0lTr6%j
zhw;bsOfD8To5T3ydL|c(o6TYT2|bgG#m(k0{-mDC#o}gj7=KF7<YIBNIgCH8XL7N)
z*&N27(KESN+-we`^h_=mH=Dz_5QlNN|1-H*+-wfxi}g${7B`#2__KN@7mJ(CVf;Bg
zlZ(a8<}mKmGr3sYY!2hk>zQ0EZZ?PUC3+?oi<`}1`~^Lei^a|6FfQtuTr6%jhw&;s
zlZ(a8<}hBZXL7N)*&N1e^h_=mH=D!wi+Uy(i<`}1+@)u7vAEeB#$VDixmet64&#!Z
z$;IMka~OYF&*WlpvpI|})ib$R+-wfx%k)ex7B`#2_;Njyi^a|6Fup?1<YIBNIgGE=
zGr3sYY!2hA^h_=mH=D!wYCV&S#m(k0zDCdFVsW!MjIY%*xmet64&&?eOfD8To5T2e
zJ(G*Y&E_z^LC@r3akDv$Z`3onSlnz5<FDwMTr6%jhq3icE*3YN!}zOl7>D~mlZ(a8
z<}m)6p2@}HW^)*SUC-oVakDv$zoBPxvAEeB#y9DiTr6%jhw(S{OfD8To5T29dL|c(
zo6TW-v!2Pt;%0Lge_PMwVsW!MjK8C2a<RDC9LC?(Gr3sYY!2gF^h_=mH=D!wdwM1p
zi<`}1{Cz!>i^a|6FuqmK<YIBNIgGpYOfD8To5T1AdL|c(o6TYTLp_s=#m(k0{*j)^
z#o}gj82?z$<YIBNIgEdzXL7N)*&N0{)ib$R+-wfxwR$EOi<`}1+@oi5vAEeB#<%I2
zTr6%jhjFi-$;IMka~QAFGr3sYY!2g}>6u(CZZ?PU&-F|$7B`#2_!oL67mJ(CVZ2_?
z<YIBNIgHjbxmet64&&S7Fb?;BCKrpF&0&0pp2@}HW^)+#>6u(CZZ?PU20fFD#m(k0
z-l%7CvAEeB#+&p^E*3YN!}v};lZ(a8<}lu@XL7N)*&N1q>6u(CZZ?PU-FhY$i<`}1
z{7XHPi^a|6F#eUE$;IMka~S_x&*WlpvpI}^qi1rlxY-=W_vo2iEN(W3@fJOki^a|6
zFuqsM<YIBNIgIbqGr3sYY!2i5^-L}nH=D!ww|XWQi<`}1{D7Xx#o}gj7(b|Ia<RDC
z9LB%XGr3sYY!2goJ(G*Y&E_!Ps%LVsxY-=Wzt=OlSlnz5<868-7mJ(CVf+U@lZ(a8
z<}m)Fp2@}HW^))nq-S!mxY-=Wf6_C#Slnz5WAsce7B`#2_~AH=!~LJh#o}gj7(b$C
za<RDC9LA68nOrPxHiz+_^-L}nH=D!wF+G!u#m(k0-mYhIvAEeB#(&W>xmet64&wnm
zlZ(a8<}gn5OfD8To5OgAp2@}HW^))1>X}?DZZ?PU<9a3+i<`}1{8v4bi^a|6FfQwv
zTr6%jhw<O^OfD8To5T1CJ(G*Y&E_!vyPnC#;%0Lg|3lB@VsW!MJS;tjaaeztTr6%j
zhw+noCKrpF&0+jcJ(G*Y&E_!PrDt-nxY-=WPwAOlEN(W3@oqhni^a|6Fn(Ik<YIBN
zIgFptGr3sYY!2f+dL|c(o6TXoSI^{PakDv$_vx8jEN(W3@qRs%i^a|6Fs|sCTr6%j
z=OJ&qbmd_;?`9vpI<L1K=i%Y&<2Vn;c{qMQ9M^;6I&fSEj_bg29XPH7$93Si4jk8k
z<2vyF_d4(vKj$BP_;WnY!*L$2-q()T!SOmcUI)kTgX21ITnCQpz;PWot^>z);J6MP
z*MVPT>%iex03640297guoPpyE9B1G-1IHOS&cJa7jx+F!bO!Ey&#Ak=<np~ged_MG
zeDAwY-F@BVtIs_4^2s-yy7lmz32uyd!QrReD|bBi!ucD||JZ9@bMC<l=b!X~S3Tv^
z&;7`S^EZ9X$6WlJb8o$H{wa6f_mSU!?kyM2KmD+Cocqp;_nmsh&FA{$Qx98b?tR~>
zAOGf?&;HbztFQmLmmj(PtZTNPaLxAPFW>X}!?^gyllNS?a^>P1A6Z}fYPVif|H4;0
zdF!JhZhhOuAG-L!nOA@Iv#z`Uju)StIvi!*@d<bK*^j^ev4_WZ-1hW$zv>lFe%F0B
zpMBufw?FB^4<Ft+ZuqXVZ@cc>&pzsoAE@(BJaz7dldnDOd1s%y;o_T5zT>dNt$p!L
zcfRY~3m<uaXRbM*|NH5legFUY75*Pi@jcgFJ+iZRTz}Ky5TE<zFZzNyf9l4wHy^$}
z@$B<oeba>>y?Q=}Gyjb1ub%lGFM0ZVPk!+5)b)=(Y@NCAaW8%4xsN^l+E+aPy8A9X
z?`5BK_&A?=>P62u`G~_`KD5Wh`_5c=-pgNk?n6$!=yBIS<M8b1*M8Pxo_YVt^@oS|
z9R9?~+uwiX$~`exuAIK*{?j+l>3biz{`4*LZ57d{pMBVR-05eXzPS$%o_hM0e#iO4
z-Zx!yl|1K~Y5VAFw*NPu>jxZ8+LiY1s~6g>m;cwT=R9KT36I!%{N<l{UHrsdZ+qPr
zUiqjqr>}eRnR`C$a6KFj?aVu#beNVK<DPuX;Vf^NM}9E3U2{y&zGnLu9^;vN9v64r
ze^=i%cRg^|TTWhbn5#=qjXJ!?&o3@lC-CZc=zrnA?0X*e>weB}jn}{MWe<MP>p$^j
z58iO*;u}u#y@!kU<R`D3Jo?JXOW%9t%E>M7JAA3bjNX3F;bkBC7rNV@_NLpP_Qu<v
j_J-Rp&Xu=6c;CbCb@e@7{+Tb1OP3z}mY;w3OP78Y>oK+#

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Build.py b/UefiCpuPkg/ResetVector/Vtf0/Build.py
index 343c53b5ff..29f29ff0c2 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Build.py
+++ b/UefiCpuPkg/ResetVector/Vtf0/Build.py
@@ -1,7 +1,7 @@
## @file
# Automate the process of building the various reset vector types
#
-# Copyright (c) 2009, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2009 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -32,16 +32,19 @@ for arch in ('ia32', 'x64'):
'-o', output,
'Vtf0.nasmb',
)
+ print(f"Command : {' '.join(commandLine)}")
ret = RunCommand(commandLine)
- print '\tASM\t' + output
- if ret != 0: sys.exit(ret)
+ if ret != 0:
+ print(f"something went wrong while executing the {commandLine[-1]}")
+ sys.exit()
+ print('\tASM\t' + output)

commandLine = (
'python',
'Tools/FixupForRawSection.py',
output,
)
- print '\tFIXUP\t' + output
+ print('\tFIXUP\t' + output)
ret = RunCommand(commandLine)
if ret != 0: sys.exit(ret)

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py b/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py
index c77438a0ce..de771eba22 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py
+++ b/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py
@@ -1,7 +1,7 @@
## @file
# Apply fixup to VTF binary image for FFS Raw section
#
-# Copyright (c) 2008, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2008 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -15,6 +15,6 @@ c = ((len(d) + 4 + 7) & ~7) - 4
if c > len(d):
c -= len(d)
f = open(sys.argv[1], 'wb')
- f.write('\x90' * c)
+ f.write(b'\x90' * c)
f.write(d)
f.close()
--
2.30.2.windows.1


Re: RFC: EXT4 filesystem driver

Marvin Häuser
 

On 22.07.21 17:58, Andrew Fish wrote:


On Jul 22, 2021, at 3:24 AM, Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>> wrote:

On 22.07.21 01:12, Pedro Falcato wrote:
EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.

The Ext4Pkg implements the Simple File System Protocol for a partition
that is formatted with the EXT4 file system. This allows UEFI Drivers,
UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
on an EXT4 partition and supports booting a UEFI OS Loader from an
EXT4 partition.
This project is one of the TianoCore Google Summer of Code projects.

Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
I/O 2 Protocols, and produces the Simple File System protocol. It
allows mounting ext4 filesystems exclusively.

Brief overhead of EXT4:
Layout of an EXT2/3/4 filesystem:
(note: this driver has been developed using
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html <https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html> as
documentation).

An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
due to the similarities) is composed of various concepts:

1) Superblock
The superblock is the structure near (1024 bytes offset from the start)
the start of the partition, and describes the filesystem in general.
Here, we get to know the size of the filesystem's blocks, which features
it supports or not, whether it's been cleanly unmounted, how many blocks
we have, etc.

2) Block groups
EXT4 filesystems are divided into block groups, and each block group covers
s_blocks_per_group(8 * Block Size) blocks. Each block group has an
associated block group descriptor; these are present directly after the
superblock. Each block group descriptor contains the location of the
inode table, and the inode and block bitmaps (note these bitmaps are only
a block long, which gets us the 8 * Block Size formula covered previously).

3) Blocks
The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
Blocks can be allocated using individual block groups's bitmaps. Note
that block 0 is invalid and its presence on extents/block tables means
it's part of a file hole, and that particular location must be read as
a block full of zeros.

4) Inodes
The ext4 filesystem divides files/directories into inodes (originally
index nodes). Each file/socket/symlink/directory/etc (here on out referred
to as a file, since there is no distinction under the ext4 filesystem) is
stored as a /nameless/ inode, that is stored in some block group's inode
table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
an old filesystem), and holds various metadata about the file. Since the
largest inode structure right now is ~160 bytes, the rest of the inode
contains inline extended attributes. Inodes' data is stored using either
data blocks (under ext2/3) or extents (under ext4).

5) Extents
Ext4 inodes store data in extents. These let N contiguous logical blocks
that are represented by N contiguous physical blocks be represented by a
single extent structure, which minimizes filesystem metadata bloat and
speeds up block mapping (particularly due to the fact that high-quality
ext4 implementations like linux's try /really/ hard to make the file
contiguous, so it's common to have files with almost 0 fragmentation).
Inodes that use extents store them in a tree, and the top of the tree
is stored on i_data. The tree's leaves always start with an
EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
block.

6) Directories
Ext4 directories are files that store name -> inode mappings for the
logical directory; this is where files get their names, which means ext4
inodes do not themselves have names, since they can be linked (present)
multiple times with different names. Directories can store entries in two
different ways:
1) Classical linear directories: They store entries as a mostly-linked
mostly-list of EXT4_DIR_ENTRY.
2) Hash tree directories: These are used for larger directories, with
hundreds of entries, and are designed in a backwards-compatible way.
These are not yet implemented in the Ext4Dxe driver.

7) Journal
Ext3/4 filesystems have a journal to help protect the filesystem against
system crashes. This is not yet implemented in Ext4Dxe but is described
in detail in the Linux kernel's documentation.

The EDK2 implementation of ext4 is based only on the public documentation
available at https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html <https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html>
and
the FreeBSD ext2fs driver (available at
https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs <https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs>,
BSD-2-Clause-FreeBSD licensed). It is licensed as
SPDX-License-Identifier: BSD-2-Clause-Patent.

After a brief discussion with the community, the proposed package
location is edk2-platform/Features/Ext4Pkg
(relevant discussion: https://edk2.groups.io/g/devel/topic/83060185 <https://edk2.groups.io/g/devel/topic/83060185>).

I was the main contributor and I would like to maintain the package in
the future, if possible.
While I personally don't like it's outside of the EDK II core, I kind of get it. However I would strongly suggest to choose a more general package name, like "LinuxFsPkg", or "NixFsPkg", or maybe even just "FileSystemPkg" (and move FAT over some day?). Imagine someone wants to import BTRFS next year, should it really be "BtrfsPkg"? I understand it follows the "FatPkg" convention, but I feel like people forget FatPkg was special as to its awkward license before Microsoft allowed a change a few years ago. Maintainers.txt already has the concept of different Reviewers per subfolder, maybe it could be extended a little to have a common EDK II contributor to officially maintain the package, but have you be a Maintainer or something like a Reviewer+ to your driver? Or you could maintain the entire package of course.
Marvin,

Good point that the FatPkg was more about license boundary than anything else, so I’m not opposed to a more generic package name.

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.
I may be alone, but I strongly object. One of our projects (OpenCore) has a disgusting way of writing files because the FAT32 driver in Aptio IV firmwares may corrupt the filesystem when resizing files. To be honest, it may corrupt with other usages too and we never noticed, because basically we wrote the code to require the least amount of (complex) FS operations.

The issue with EDK II is, there is a lot of own code and a lot of users, but little testing. By that I do not mean that developers do not test their code, but that nobody sits down and performs all sorts of FS manipulations in all sorts of orders and closely observes the result for regression-testing. Users will not really test it either, as UEFI to them should just somehow boot to Windows. If at least the code was shared with a codebase that is known-trusted (e.g. the Linux kernel itself), that'd be much easier to trust, but realistically this is not going to happen.
My point is, if a company like AMI cannot guarantee writing does not damage the FS for a very simple FS, how do you plan to guarantee yours doesn't for a much more complex FS? I'd rather have only one simple FS type that supports writing for most use-cases (e.g. logging).

At the very least I would beg you to have a PCD to turn write support off - if it will be off by default, that'd be great of course. :)
Was there any discussion yet as to why write support is needed in the first place you could point me to?
I think having a default PCD option of read only is a good idea.

EFI on Mac carries HFS+ and APFS EFI file system drivers and both of those are read only for safety, security, and to avoid the need to validate them. So I think some products may want to have the option to ship read only versions of the file system.

Seems like having EFI base file system tests would be useful. I’d imaging with OVMF it would be possible to implement a very robust test infrastructure. Seems like the hard bits would be generating the test cases and figuring out how to validate the tests did the correct thing. I’m guess the OS based file system drivers are robust and try to work around bugs gracefully? Maybe there is a way to turn on OS logging, or even run an OS based fsck on the volume after the tests complete. Regardless this seems like an interesting project, maybe we can add it to next years GSoC?
Great idea, maybe it could be added to that wiki list of topic suggestions (preferably close to the top)? :)

Best regards,
Marvin


Thanks,

Andrew Fish

Thanks for your work!

Best regards,
Marvin

The driver's handling of unclean unmounting through forced shutdown is unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato






Re: RFC: EXT4 filesystem driver

Andrew Fish
 



On Jul 22, 2021, at 3:24 AM, Marvin Häuser <mhaeuser@...> wrote:

On 22.07.21 01:12, Pedro Falcato wrote:
EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.

The Ext4Pkg implements the Simple File System Protocol for a partition
that is formatted with the EXT4 file system. This allows UEFI Drivers,
UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
on an EXT4 partition and supports booting a UEFI OS Loader from an
EXT4 partition.
This project is one of the TianoCore Google Summer of Code projects.

Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
I/O 2 Protocols, and produces the Simple File System protocol. It
allows mounting ext4 filesystems exclusively.

Brief overhead of EXT4:
Layout of an EXT2/3/4 filesystem:
(note: this driver has been developed using
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
documentation).

An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
due to the similarities) is composed of various concepts:

1) Superblock
The superblock is the structure near (1024 bytes offset from the start)
the start of the partition, and describes the filesystem in general.
Here, we get to know the size of the filesystem's blocks, which features
it supports or not, whether it's been cleanly unmounted, how many blocks
we have, etc.

2) Block groups
EXT4 filesystems are divided into block groups, and each block group covers
s_blocks_per_group(8 * Block Size) blocks. Each block group has an
associated block group descriptor; these are present directly after the
superblock. Each block group descriptor contains the location of the
inode table, and the inode and block bitmaps (note these bitmaps are only
a block long, which gets us the 8 * Block Size formula covered previously).

3) Blocks
The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
Blocks can be allocated using individual block groups's bitmaps. Note
that block 0 is invalid and its presence on extents/block tables means
it's part of a file hole, and that particular location must be read as
a block full of zeros.

4) Inodes
The ext4 filesystem divides files/directories into inodes (originally
index nodes). Each file/socket/symlink/directory/etc (here on out referred
to as a file, since there is no distinction under the ext4 filesystem) is
stored as a /nameless/ inode, that is stored in some block group's inode
table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
an old filesystem), and holds various metadata about the file. Since the
largest inode structure right now is ~160 bytes, the rest of the inode
contains inline extended attributes. Inodes' data is stored using either
data blocks (under ext2/3) or extents (under ext4).

5) Extents
Ext4 inodes store data in extents. These let N contiguous logical blocks
that are represented by N contiguous physical blocks be represented by a
single extent structure, which minimizes filesystem metadata bloat and
speeds up block mapping (particularly due to the fact that high-quality
ext4 implementations like linux's try /really/ hard to make the file
contiguous, so it's common to have files with almost 0 fragmentation).
Inodes that use extents store them in a tree, and the top of the tree
is stored on i_data. The tree's leaves always start with an
EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
block.

6) Directories
Ext4 directories are files that store name -> inode mappings for the
logical directory; this is where files get their names, which means ext4
inodes do not themselves have names, since they can be linked (present)
multiple times with different names. Directories can store entries in two
different ways:
1) Classical linear directories: They store entries as a mostly-linked
mostly-list of EXT4_DIR_ENTRY.
2) Hash tree directories: These are used for larger directories, with
hundreds of entries, and are designed in a backwards-compatible way.
These are not yet implemented in the Ext4Dxe driver.

7) Journal
Ext3/4 filesystems have a journal to help protect the filesystem against
system crashes. This is not yet implemented in Ext4Dxe but is described
in detail in the Linux kernel's documentation.

The EDK2 implementation of ext4 is based only on the public documentation
available at https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
and
the FreeBSD ext2fs driver (available at
https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs,
BSD-2-Clause-FreeBSD licensed). It is licensed as
SPDX-License-Identifier: BSD-2-Clause-Patent.

After a brief discussion with the community, the proposed package
location is edk2-platform/Features/Ext4Pkg
(relevant discussion: https://edk2.groups.io/g/devel/topic/83060185).

I was the main contributor and I would like to maintain the package in
the future, if possible.

While I personally don't like it's outside of the EDK II core, I kind of get it. However I would strongly suggest to choose a more general package name, like "LinuxFsPkg", or "NixFsPkg", or maybe even just "FileSystemPkg" (and move FAT over some day?). Imagine someone wants to import BTRFS next year, should it really be "BtrfsPkg"? I understand it follows the "FatPkg" convention, but I feel like people forget FatPkg was special as to its awkward license before Microsoft allowed a change a few years ago. Maintainers.txt already has the concept of different Reviewers per subfolder, maybe it could be extended a little to have a common EDK II contributor to officially maintain the package, but have you be a Maintainer or something like a Reviewer+ to your driver? Or you could maintain the entire package of course.


Marvin,

Good point that the FatPkg was more about license boundary than anything else, so I’m not opposed to a more generic package name. 

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.

I may be alone, but I strongly object. One of our projects (OpenCore) has a disgusting way of writing files because the FAT32 driver in Aptio IV firmwares may corrupt the filesystem when resizing files. To be honest, it may corrupt with other usages too and we never noticed, because basically we wrote the code to require the least amount of (complex) FS operations.

The issue with EDK II is, there is a lot of own code and a lot of users, but little testing. By that I do not mean that developers do not test their code, but that nobody sits down and performs all sorts of FS manipulations in all sorts of orders and closely observes the result for regression-testing. Users will not really test it either, as UEFI to them should just somehow boot to Windows. If at least the code was shared with a codebase that is known-trusted (e.g. the Linux kernel itself), that'd be much easier to trust, but realistically this is not going to happen.
My point is, if a company like AMI cannot guarantee writing does not damage the FS for a very simple FS, how do you plan to guarantee yours doesn't for a much more complex FS? I'd rather have only one simple FS type that supports writing for most use-cases (e.g. logging).

At the very least I would beg you to have a PCD to turn write support off - if it will be off by default, that'd be great of course. :)
Was there any discussion yet as to why write support is needed in the first place you could point me to?


I think having a default PCD option of read only is a good idea. 

EFI on Mac carries HFS+ and APFS EFI file system drivers and both of those are read only for safety, security, and to avoid the need to validate them. So I think some products may want to have the option to ship read only versions of the file system. 

Seems like having EFI base file system tests would be useful. I’d imaging with OVMF it would be possible to implement a very robust test infrastructure. Seems like the hard bits would be generating the test cases and figuring out how to validate the tests did the correct thing. I’m guess the OS based file system drivers are robust and try to work around bugs gracefully? Maybe there is a way to turn on OS logging, or even run an OS based fsck on the volume after the tests complete. Regardless this seems like an interesting project, maybe we can add it to next years GSoC?

Thanks,

Andrew Fish

Thanks for your work!

Best regards,
Marvin

The driver's handling of unclean unmounting through forced shutdown is unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato









Re: ArmVirt and Self-Updating Code

Ard Biesheuvel
 

On Thu, 22 Jul 2021 at 16:54, Bret Barkelew <Bret.Barkelew@microsoft.com> wrote:

Expanding audience to the full dev list…

See below…



- Bret



From: Thomas Abraham
Sent: Wednesday, July 7, 2021 11:07 PM
To: Bret Barkelew; Ard Biesheuvel (TianoCore); Lindholm, Leif; Laszlo Ersek; Marvin Häuser; Sami Mujawar
Cc: nd
Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code



+ Sami



From: Bret Barkelew <Bret.Barkelew@microsoft.com>
Sent: Thursday, July 8, 2021 11:05 AM
To: Thomas Abraham <thomas.abraham@arm.com>; Ard Biesheuvel (TianoCore) <ardb+tianocore@kernel.org>; Lindholm, Leif <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>; Marvin Häuser <mhaeuser@posteo.de>
Subject: ArmVirt and Self-Updating Code



All,



Marvin asked me a question on the UEFI Talkbox Discord that’s a little beyond my ken…



“There is self-relocating code in ArmVirtPkg:

https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165

According to comments in the ASM, it seems like this is for Linux-based RAM boot (I saw further stuff for KVM, so it makes sense I guess?). It seems unfortunate it cannot be mapped into a known address range so that self-relocation is not necessary, but that's out of my scope to understand.
"Mapping" implies that the MMU is on, but this code boots with the MMU
off. Unlike x86, ARM does not define any physical address ranges that
are guaranteed to be backed by DRAM, so a portable image either needs
to be fully position independent, or carry the metadata it needs to
relocate itself as it is invoked.



“Now, StandaloneMmPkg has similar (self-)relocation code too: https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386

Because I cannot find such elsewhere, I assume it must be for the same ARM virtualised environment as above.
No.

The binary it applies the Relocations to is documented to be the Standalone MM core, but in fact SecCore is located:

https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c#L131-L158



“This yields the following questions to me:

1) What even invokes Standalone MM on ARM? It is documented it is spawned during SEC, but I could not find any actual invocation.
It is not spawned by the normal world code that runs UEFI. It is a
secure world component that runs in a completely different execution
context (TrustZone). The code does run with the MMU enabled from the
start, but running from an a priori fixed offset was considered to be
a security hazard, so we added self relocation support.

The alternative would have been to add metadata to the StMmCore
component that can be interpreted by the secure world component that
loads it, but this would go beyond any existing specs, and make
portability more problematic.

2) Why does Standalone MM (self-)relocation locate SecCore? Should it not already have been relocated with the code from ArmPlatformPkg? Is Standalone MM embedded into ARM SecCore?
No and no. Standalone MM has nothing to do with the code that runs as
part of UEFI itself. ArmPlatformPkg is completely separate from
StandaloneMmPkg.

3) Why is SecCore the only module relocated? Are all others guaranteed to be "properly" loaded?
SecCore contains a PE/COFF loader, so all subsequent modules are
loaded normally. This is similar to the ArmVirtQemuKernel
self-relocating SEC module, which only relocates itself in this
manner, and relies on standard PE/COFF metadata for loading other
modules.


4) Is there maybe some high-level documented about the ARM boot flow? It seems to be significantly different from the x86 routes quite vastly.”
trustedfirmware.org may have some useful documentation.



Hoping that one of you could get me closer to an answer for him. Also happy to take this to the greater mailing list, but thought I’d avoid churn.



Thanks in advance!

- Bret




Re: [staging/edk2-redfish-client Tools PATCH 6/6] RedfishClientPkg/Redfish-Profile-Simulator: Add requirements

Nickle Wang
 

Reviewed-by: Nickle Wang <nickle.wang@...>

Thanks,
Nickle


From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: Wang, Nickle (HPS SW) <nickle.wang@...>; Liming Gao <gaoliming@...>
Subject: [staging/edk2-redfish-client Tools PATCH 6/6] RedfishClientPkg/Redfish-Profile-Simulator: Add requirements
 
add requirements.txt for the required python module

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Nickle Wang <nickle.wang@...>
Cc: Liming Gao <gaoliming@...>
---
 .../Tools/Redfish-Profile-Simulator/requirements.txt            | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
new file mode 100644
index 0000000000..88807d87c2
--- /dev/null
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
@@ -0,0 +1,2 @@
+flask==1.1.1
+pyOpenSSL
--
2.17.1


Re: [staging/edk2-redfish-client Tools PATCH 5/6] RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory resource

Nickle Wang
 

Reviewed-by: Nickle Wang <nickle.wang@...>

Thanks,
Nickle


From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: Wang, Nickle (HPS SW) <nickle.wang@...>; Liming Gao <gaoliming@...>
Subject: [staging/edk2-redfish-client Tools PATCH 5/6] RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory resource
 
Add ETAG support on Memory resource.

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Nickle Wang <nickle.wang@...>
Cc: Liming Gao <gaoliming@...>
---
 .../Redfish-Profile-Simulator/v1sim/systems.py      | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index 690101fb10..de4b839aeb 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -18,6 +18,7 @@ from .resource import RfResource, RfCollection
 from .storage import RfSimpleStorageCollection, RfSmartStorage
 import flask
 import json
+import hashlib
 from collections import OrderedDict
 
 class RfSystemsCollection(RfCollection):
@@ -142,13 +143,25 @@ class RfMemoryCollection(RfCollection):
         self.res_data["Members"].append({"@odata.id":newMemoryUrl})
 
         post_data["@odata.id"] = newMemoryUrl
+
+        md5 = hashlib.md5()
+        md5.update(json.dumps(post_data).encode("utf-8"))
+        etag_str = 'W/"' + md5.hexdigest() + '"'
+        post_data["@odata.etag"] = etag_str
         self.elements[str(newMemoryIdx)] = post_data
 
         resp = flask.Response(json.dumps(post_data,indent=4))
         resp.headers["Location"] = newMemoryUrl
+        resp.headers["ETag"] = etag_str
+
         return 0, 200, None, resp
 
     def patch_memory(self, Idx, patch_data):
+        md5 = hashlib.md5()
+        md5.update(json.dumps(patch_data).encode("utf-8"))
+        etag_str = 'W/"' + md5.hexdigest() + '"'
+        patch_data["@odata.etag"] = etag_str
+
         self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
         resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
         return 0, 200, None, resp
--
2.17.1


Re: [staging/edk2-redfish-client Tools PATCH 4/6] RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory Collection

Nickle Wang
 

Reviewed-by: Nickle Wang <nickle.wang@...>

Thanks,
Nickle


From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: Wang, Nickle (HPS SW) <nickle.wang@...>; Liming Gao <gaoliming@...>
Subject: [staging/edk2-redfish-client Tools PATCH 4/6] RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory Collection
 
Add POST and PATCH methods on Memory collection and resource.

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Nickle Wang <nickle.wang@...>
Cc: Liming Gao <gaoliming@...>
---
 .../v1sim/redfishURIs.py                      | 25 +++++++++++
 .../v1sim/systems.py                          | 43 +++++++++++++++++++
 2 files changed, 68 insertions(+)

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
index 3c912f7ce1..35d3794cc6 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
@@ -1,6 +1,7 @@
 #
 # Copyright Notice:
 # Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -308,6 +309,30 @@ def rfApi_SimpleServer(root, versions, host="127.0.0.1", port=5000, cert="", key
         else:
             return err_string, status_code
 
+    @app.route("/redfish/v1/Systems/<string:system_id>/Memory", methods=['POST'])
+    @auth.rfAuthRequired
+    def rf_computer_memory_post(system_id):
+        print ("in POST memory collection")
+        rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+        print("rdata:{}".format(rdata))
+        rc, status_code, err_string, resp = root.components['Systems'].get_element(system_id).components['Memory'].post_resource(rdata)
+        if rc == 0:
+            return resp, status_code
+        else:
+            return err_string, status_code
+
+    @app.route("/redfish/v1/Systems/<string:system_id>/Memory/<string:MemoryIdx>", methods=['PATCH'])
+    @auth.rfAuthRequired
+    def rf_computer_memory_patch(system_id, MemoryIdx):
+        print ("in PATCH memory[%s] resource" % MemoryIdx)
+        rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+        print("rdata:{}".format(rdata))
+        rc, status_code, err_string, resp = root.components['Systems'].get_element(system_id).components['Memory'].patch_memory(MemoryIdx, rdata)
+        if rc == 0:
+            return resp, status_code
+        else:
+            return err_string, status_code
+
     def resolve_path(service, path):
         parts = path.split('/')
         result = service
diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index b8b3788054..690101fb10 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -2,6 +2,7 @@
 # Copyright Notice:
 #
 # Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -123,9 +124,50 @@ class RfSystemObj(RfResource):
 
 # subclass Logs Collection
 class RfMemoryCollection(RfCollection):
+    def final_init_processing(self, base_path, rel_path):
+        self.maxIdx = self.res_data["Members@..."]
+
     def element_type(self):
         return RfMemory
 
+    def post_resource(self, post_data):
+        print("Members@...:{}".format(self.res_data["Members@..."]))
+        print("Members:{}".format(self.res_data["Members"]))
+        print("post_data:{}".format(post_data))
+
+        self.res_data["Members@..."] = self.res_data["Members@..."] + 1
+        self.maxIdx = self.maxIdx + 1
+        newMemoryIdx = self.maxIdx
+        newMemoryUrl = self.res_data["@odata.id"] + "/" + str(newMemoryIdx)
+        self.res_data["Members"].append({"@odata.id":newMemoryUrl})
+
+        post_data["@odata.id"] = newMemoryUrl
+        self.elements[str(newMemoryIdx)] = post_data
+
+        resp = flask.Response(json.dumps(post_data,indent=4))
+        resp.headers["Location"] = newMemoryUrl
+        return 0, 200, None, resp
+
+    def patch_memory(self, Idx, patch_data):
+        self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
+        resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
+        return 0, 200, None, resp
+
+    def get_memory(self, Idx):
+        return json.dumps(self.elements[Idx],indent=4)
+
+    def delete_memory(self, Idx):
+        print("in delete_memory")
+
+        resp = flask.Response(json.dumps(self.elements[Idx],indent=4))
+
+        self.elements.pop(Idx)
+        self.res_data["Members@..."] = self.res_data["Members@..."] - 1
+
+        newMemoryUrl = self.res_data["@odata.id"] + "/" + str(Idx)
+        self.res_data["Members"].remove({"@odata.id":newMemoryUrl})
+        return 0, 200, None, resp
+
 
 class RfMemory(RfResource):
     pass
@@ -267,3 +309,4 @@ class RfBootOptionCollection(RfCollection):
         return 0, 200, None, resp
 
 class RfBootOption(RfResource):
+    pass
--
2.17.1


Re: ArmVirt and Self-Updating Code

Bret Barkelew
 

Expanding audience to the full dev list…

See below…

 

- Bret

 

From: Thomas Abraham
Sent: Wednesday, July 7, 2021 11:07 PM
To: Bret Barkelew; Ard Biesheuvel (TianoCore); Lindholm, Leif; Laszlo Ersek; Marvin Häuser; Sami Mujawar
Cc: nd
Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code

 

+ Sami

 

From: Bret Barkelew <Bret.Barkelew@...>
Sent: Thursday, July 8, 2021 11:05 AM
To: Thomas Abraham <thomas.abraham@...>; Ard Biesheuvel (TianoCore) <ardb+tianocore@...>; Lindholm, Leif <leif@...>; Laszlo Ersek <lersek@...>; Marvin Häuser <mhaeuser@...>
Subject: ArmVirt and Self-Updating Code

 

All,

 

Marvin asked me a question on the UEFI Talkbox Discord that’s a little beyond my ken…

 

“There is self-relocating code in ArmVirtPkg:

https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165

According to comments in the ASM, it seems like this is for Linux-based RAM boot (I saw further stuff for KVM, so it makes sense I guess?). It seems unfortunate it cannot be mapped into a known address range so that self-relocation is not necessary, but that's out of my scope to understand.

 

“Now, StandaloneMmPkg has similar (self-)relocation code too: https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386

Because I cannot find such elsewhere, I assume it must be for the same ARM virtualised environment as above. The binary it applies the Relocations to is documented to be the Standalone MM core, but in fact SecCore is located:

https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c#L131-L158

 

“This yields the following questions to me:

1) What even invokes Standalone MM on ARM? It is documented it is spawned during SEC, but I could not find any actual invocation.

2) Why does Standalone MM (self-)relocation locate SecCore? Should it not already have been relocated with the code from ArmPlatformPkg? Is Standalone MM embedded into ARM SecCore?

3) Why is SecCore the only module relocated? Are all others guaranteed to be "properly" loaded?

4) Is there maybe some high-level documented about the ARM boot flow? It seems to be significantly different from the x86 routes quite vastly.”

 

Hoping that one of you could get me closer to an answer for him. Also happy to take this to the greater mailing list, but thought I’d avoid churn.

 

Thanks in advance!

- Bret

 

 


Re: [PATCH v1 6/6] UefiPayloadPkg: LinuxBoot: use a text format for the configuration block.

Cheng-Chieh Huang <chengchieh@...>
 


On Thu, Jul 22, 2021 at 1:09 AM Marvin Häuser <mhaeuser@...> wrote:


On 21.07.21 15:23, Cheng-Chieh Huang via groups.io wrote:
> From: Trammell Hudson <hudson@...>
>
> This adds a text command line for the UefiPayloadPkg that uses
> a textual magic number 'LnxBoot1' and a series of white-space
> separated key=value[,value...] pairs for the parameters.
>
> The v1 binary configuration structure is used if it is present instead
> for backwards compatability.
>
> Currently supported text command line arguments are are:
>
> * `serial=baud,base,width,type,hz,pci`
> (only `baud` needs to be specified, the rest have reasonable
> defaults)
>
> * `mem=start,end,type`
> Types are based on `/sys/firmware/memmaps/*/types`:
>      1 == "System RAM"
>      3 == "ACPI Tables"
>      4 == "ACPI Non-volatile Storage"
>      5 == "Reserved"
>
> * `ACPI20=base` pointer to RDSP (from `/sys/firmware/efi/systab`)
>
> * `SMBIOS=base` pointer to the SMBIOS table (also from the EFI table)
>
> Signed-off-by: Cheng-Chieh Huang <chengchieh@...>
> ---
>   UefiPayloadPkg/Include/Linuxboot.h             |  17 +-
>   UefiPayloadPkg/Library/LbParseLib/LbParseLib.c | 252 +++++++++++++++++---
>   2 files changed, 230 insertions(+), 39 deletions(-)
>
> diff --git a/UefiPayloadPkg/Include/Linuxboot.h b/UefiPayloadPkg/Include/Linuxboot.h
> index 34ca18069983..56b39b5a09ff 100644
> --- a/UefiPayloadPkg/Include/Linuxboot.h
> +++ b/UefiPayloadPkg/Include/Linuxboot.h
> @@ -24,8 +24,7 @@ typedef struct MemoryMapEntryStruct {
>     UINT32 Type;
>   } MemoryMapEntry;
>   
> -typedef struct UefiPayloadConfigStruct {
> -  UINT64 Version;
> +typedef struct {
>     UINT64 AcpiBase;
>     UINT64 AcpiSize;
>     UINT64 SmbiosBase;
> @@ -33,10 +32,22 @@ typedef struct UefiPayloadConfigStruct {
>     SerialPortConfig SerialConfig;
>     UINT32 NumMemoryMapEntries;
>     MemoryMapEntry MemoryMapEntries[0];
> +} UefiPayloadConfigV1;
> +
> +typedef struct UefiPayloadConfigStruct {
> +  UINT64 Version;
> +  union {
> +    UefiPayloadConfigV1 v1;
> +    struct {
> +      char cmdline[0]; // up to 64 KB
> +    } v2;
> +  } config;
>   } UefiPayloadConfig;
>   #pragma pack()
>   
> -#define UEFI_PAYLOAD_CONFIG_VERSION 1
> +// magic version config is "LnxBoot1"
> +#define UEFI_PAYLOAD_CONFIG_VERSION1 1
> +#define UEFI_PAYLOAD_CONFIG_VERSION2 0x31746f6f42786e4cULL
>   
>   #define LINUXBOOT_MEM_RAM 1
>   #define LINUXBOOT_MEM_DEFAULT 2
> diff --git a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> index 34bfb6a1073f..5e68091cac91 100644
> --- a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> +++ b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> @@ -1,13 +1,12 @@
>   /** @file
> -  This library will parse the linuxboot table in memory and extract those required
> -  information.
> +  This library will parse the linuxboot table in memory and extract those
> +required information.
>   
>     Copyright (c) 2021, the u-root Authors. All rights reserved.<BR>
>     SPDX-License-Identifier: BSD-2-Clause-Patent
>   
>   **/
>   
> -
>   #include <IndustryStandard/Acpi.h>
>   #include <IndustryStandard/SmBios.h>
>   #include <Library/BaseLib.h>
> @@ -18,17 +17,42 @@
>   #include <Library/PcdLib.h>
>   #include <Linuxboot.h>
>   #include <Uefi/UefiBaseType.h>
> +#include <stdint.h>
> +#include <stdlib.h>
> +//#include <string.h>
> +//#include <ctype.h>
> +
> +#define strncmp(a, b, n) AsciiStrnCmp((a), (b), (n))
> +
> +static uint64_t parse_int(const char* s, char** end) {
> +  UINT64 x;
> +
> +  if (s[0] == '0' && s[1] == 'x')
> +    AsciiStrHexToUint64S(s, end, &x);
> +  else
> +    AsciiStrDecimalToUint64S(s, end, &x);
> +
> +  return x;
> +}
> +
> +static int isspace(const char c) { return c == ' ' || c == '\t' || c == '\n'; }
>   
>   // Retrieve UefiPayloadConfig from Linuxboot's uefiboot
> -UefiPayloadConfig* GetUefiPayLoadConfig() {
> -  UefiPayloadConfig* config =
> +const UefiPayloadConfig* GetUefiPayLoadConfig() {
> +  const UefiPayloadConfig* config =
>         (UefiPayloadConfig*)(UINTN)(PcdGet32(PcdPayloadFdMemBase) - SIZE_64KB);
> -  if (config->Version != UEFI_PAYLOAD_CONFIG_VERSION) {
> -    DEBUG((DEBUG_ERROR, "Expect payload config version: %d, but get %d\n",
> -           UEFI_PAYLOAD_CONFIG_VERSION, config->Version));
> -    CpuDeadLoop ();
> -  }
> -  return config;
> +
> +  if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION1 ||
> +      config->Version == UEFI_PAYLOAD_CONFIG_VERSION2)
> +    return config;
> +
> +  DEBUG((DEBUG_ERROR,
> +         "Expect payload config version %016lx or %016lx, but get %016lx\n",
> +         UEFI_PAYLOAD_CONFIG_VERSION1, UEFI_PAYLOAD_CONFIG_VERSION2,
> +         config->Version));
> +  CpuDeadLoop();
> +  while (1)
> +    ;
>   }
>   
>   // Align the address and add memory rang to MemInfoCallback
> @@ -54,6 +78,57 @@ void AddMemoryRange(IN BL_MEM_INFO_CALLBACK MemInfoCallback, IN UINTN start,
>     MemInfoCallback(&MemoryMap, NULL);
>   }
>   
> +const char* cmdline_next(const char* cmdline, const char** option) {
> +  // at the end of the string, we're done
> +  if (!cmdline || *cmdline == '\0') return NULL;
> +
> +  // skip any leading whitespace
> +  while (isspace(*cmdline)) cmdline++;
> +
> +  // if we've hit the end of the string, we're done
> +  if (*cmdline == '\0') return NULL;
> +
> +  *option = cmdline;
> +
> +  // find the end of this option or the string
> +  while (!isspace(*cmdline) && *cmdline != '\0') cmdline++;
> +
> +  // cmdline points to the whitespace or end of string
> +  return cmdline;
> +}
> +
> +int cmdline_ints(const char* option, uint64_t args[], int max) {
> +  // skip any leading text up to an '='
> +  const char* s = option;
> +  while (1) {
> +    const char c = *s++;
> +    if (c == '=') break;
> +
> +    if (c == '\0' || isspace(c)) {
> +      s = option;
> +      break;
> +    }
> +  }
> +
> +  for (int i = 0; i < max; i++) {
> +    char* end;
> +    args[i] = parse_int(s, &end);
> +
> +    // end of string or end of the option?
> +    if (*end == '\0' || isspace(*end)) return i + 1;
> +
> +    // not separator? signal an error if we have consumed any ints,
> +    // otherwise return 0 saying that none were found
> +    if (*end != ',') return i == 0 ? 0 : -1;
> +
> +    // skip the , and get the next value
> +    s = end + 1;
> +  }
> +
> +  // too many values!
> +  return -1;
> +}
> +
>   /**
>     Acquire the memory information from the linuxboot table in memory.
>   
> @@ -67,20 +142,50 @@ void AddMemoryRange(IN BL_MEM_INFO_CALLBACK MemInfoCallback, IN UINTN start,
>   RETURN_STATUS
>   EFIAPI
>   ParseMemoryInfo(IN BL_MEM_INFO_CALLBACK MemInfoCallback, IN VOID* Params) {
> -  UefiPayloadConfig* config;
> -  int i;
> +  const UefiPayloadConfig* config = GetUefiPayLoadConfig();
> +  if (!config) {
> +    DEBUG(
> +        (DEBUG_ERROR, "ParseMemoryInfo: Could not find UEFI Payload config\n"));
> +    return RETURN_SUCCESS;
> +  }
> +
> +  if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION1) {
> +    const UefiPayloadConfigV1* config1 = &config->config.v1;
> +    DEBUG(
> +        (DEBUG_INFO, "MemoryMap #entries: %d\n", config1->NumMemoryMapEntries));
> +
> +    for (int i = 0; i < config1->NumMemoryMapEntries; i++) {
> +      const MemoryMapEntry* entry = &config1->MemoryMapEntries[i];
> +      DEBUG((DEBUG_INFO, "Start: 0x%lx End: 0x%lx Type:%d\n", entry->Start,
> +             entry->End, entry->Type));
> +      AddMemoryRange(MemInfoCallback, entry->Start, entry->End, entry->Type);
> +    }
> +  } else
>   
> -  config = GetUefiPayLoadConfig();
> +      if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION2) {
> +    const char* cmdline = config->config.v2.cmdline;
> +    const char* option;
> +    uint64_t args[3];
>   
> -  DEBUG((DEBUG_INFO, "MemoryMap #entries: %d\n", config->NumMemoryMapEntries));
> +    // look for the mem=start,end,type
> +    while ((cmdline = cmdline_next(cmdline, &option))) {
> +      if (strncmp(option, "mem=", 4) != 0) continue;
>   
> -  MemoryMapEntry* entry = &config->MemoryMapEntries[0];
> -  for (i = 0; i < config->NumMemoryMapEntries; i++) {
> -    DEBUG((DEBUG_INFO, "Start: 0x%lx End: 0x%lx Type:%d\n", entry->Start,
> -           entry->End, entry->Type));
> -    AddMemoryRange(MemInfoCallback, entry->Start, entry->End, entry->Type);
> -    entry++;
> +      if (cmdline_ints(option, args, 3) != 3) {
> +        DEBUG((DEBUG_ERROR, "Parse error: '%a'\n", option));
> +        continue;
> +      }
> +
> +      const uint64_t start = args[0];
> +      const uint64_t end = args[1];
> +      const uint64_t type = args[2];
> +
> +      DEBUG(
> +          (DEBUG_INFO, "Start: 0x%lx End: 0x%lx Type:%d\n", start, end, type));
> +      AddMemoryRange(MemInfoCallback, start, end, type);
> +    }
>     }
> +
>     return RETURN_SUCCESS;
>   }
>   
> @@ -96,14 +201,52 @@ ParseMemoryInfo(IN BL_MEM_INFO_CALLBACK MemInfoCallback, IN VOID* Params) {
>   RETURN_STATUS
>   EFIAPI
>   ParseSystemTable(OUT SYSTEM_TABLE_INFO* SystemTableInfo) {
> -  UefiPayloadConfig* config;
> +  const UefiPayloadConfig* config = GetUefiPayLoadConfig();
> +  if (!config) {
> +    DEBUG((DEBUG_ERROR,
> +           "ParseSystemTable: Could not find UEFI Payload config\n"));
> +    return RETURN_SUCCESS;
> +  }
>   
> -  config = GetUefiPayLoadConfig();
> -  SystemTableInfo->AcpiTableBase = config->AcpiBase;
> -  SystemTableInfo->AcpiTableSize = config->AcpiSize;
> +  if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION1) {
> +    const UefiPayloadConfigV1* config1 = &config->config.v1;
> +    SystemTableInfo->AcpiTableBase = config1->AcpiBase;
> +    SystemTableInfo->AcpiTableSize = config1->AcpiSize;
>   
> -  SystemTableInfo->SmbiosTableBase = config->SmbiosBase;
> -  SystemTableInfo->SmbiosTableSize = config->SmbiosSize;
> +    SystemTableInfo->SmbiosTableBase = config1->SmbiosBase;
> +    SystemTableInfo->SmbiosTableSize = config1->SmbiosSize;
> +  } else
> +
> +      if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION2) {
> +    const char* cmdline = config->config.v2.cmdline;
> +    const char* option;
> +    uint64_t args[2];
> +
> +    // look for the acpi config
> +    while ((cmdline = cmdline_next(cmdline, &option))) {
> +      if (strncmp(option, "ACPI20=", 7) == 0) {
> +        const int count = cmdline_ints(option, args, 2);
> +        if (count < 0) {
> +          DEBUG((DEBUG_ERROR, "Parse error: '%a'\n", option));
> +          continue;
> +        }
> +
> +        if (count > 0) SystemTableInfo->AcpiTableBase = args[0];
> +        if (count > 1) SystemTableInfo->AcpiTableSize = args[1];
> +      }
> +
> +      if (strncmp(option, "SMBIOS=", 7) == 0) {
> +        const int count = cmdline_ints(option, args, 2);
> +        if (count < 0) {
> +          DEBUG((DEBUG_ERROR, "Parse error: '%a'\n", option));
> +          continue;
> +        }
> +
> +        if (count > 0) SystemTableInfo->SmbiosTableBase = args[0];
> +        if (count > 1) SystemTableInfo->SmbiosTableSize = args[1];
> +      }

Sorry, from only a quick peak, can this not leave {Acpi,Smbios}TableBase
and {Acpi,Smbios}TableSize undefined entirely, while returning
RETURN_SUCCESS?
Even if not, it looks kind of odd a command-line argument can change the
base address without changing the size, is there a documentation of this
behaviour?
What is the structure supposed to carry if no such arguments are given
at all?

Thanks for your time!

Best regards,
Marvin

> +    }
> +  }
>   
>     return RETURN_SUCCESS;
>   }
> @@ -120,15 +263,52 @@ ParseSystemTable(OUT SYSTEM_TABLE_INFO* SystemTableInfo) {
>   RETURN_STATUS
>   EFIAPI
>   ParseSerialInfo(OUT SERIAL_PORT_INFO* SerialPortInfo) {
> -  UefiPayloadConfig* config;
> -  config = GetUefiPayLoadConfig();
> -
> -  SerialPortInfo->BaseAddr = config->SerialConfig.BaseAddr;
> -  SerialPortInfo->RegWidth = config->SerialConfig.RegWidth;
> -  SerialPortInfo->Type = config->SerialConfig.Type;
> -  SerialPortInfo->Baud = config->SerialConfig.Baud;
> -  SerialPortInfo->InputHertz = config->SerialConfig.InputHertz;
> -  SerialPortInfo->UartPciAddr = config->SerialConfig.UartPciAddr;
> +  // fill in some reasonable defaults
> +  SerialPortInfo->BaseAddr = 0x3f8;
> +  SerialPortInfo->RegWidth = 1;
> +  SerialPortInfo->Type = 1;  // uefi.SerialPortTypeIO
> +  SerialPortInfo->Baud = 115200;
> +  SerialPortInfo->InputHertz = 1843200;
> +  SerialPortInfo->UartPciAddr = 0;
> +
> +  const UefiPayloadConfig* config = GetUefiPayLoadConfig();
> +  if (!config) {
> +    DEBUG((DEBUG_ERROR, "ParseSerialInfo: using default config\n"));
> +    return RETURN_SUCCESS;
> +  }
> +
> +  if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION1) {
> +    const UefiPayloadConfigV1* config1 = &config->config.v1;
> +    SerialPortInfo->BaseAddr = config1->SerialConfig.BaseAddr;
> +    SerialPortInfo->RegWidth = config1->SerialConfig.RegWidth;
> +    SerialPortInfo->Type = config1->SerialConfig.Type;
> +    SerialPortInfo->Baud = config1->SerialConfig.Baud;
> +    SerialPortInfo->InputHertz = config1->SerialConfig.InputHertz;
> +    SerialPortInfo->UartPciAddr = config1->SerialConfig.UartPciAddr;
> +  } else
> +
> +      if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION2) {
> +    const char* cmdline = config->config.v2.cmdline;
> +    const char* option;
> +    uint64_t args[6] = {};
> +
> +    while ((cmdline = cmdline_next(cmdline, &option))) {
> +      if (strncmp(option, "serial=", 7) != 0) continue;
> +
> +      const int count = cmdline_ints(option, args, 6);
> +      if (count < 0) {
> +        DEBUG((DEBUG_ERROR, "Parse error: %a\n", option));
> +        continue;
> +      }
> +
> +      if (count > 0) SerialPortInfo->Baud = args[0];
> +      if (count > 1) SerialPortInfo->BaseAddr = args[1];
> +      if (count > 2) SerialPortInfo->RegWidth = args[2];
> +      if (count > 3) SerialPortInfo->Type = args[3];
> +      if (count > 4) SerialPortInfo->InputHertz = args[4];
> +      if (count > 5) SerialPortInfo->UartPciAddr = args[5];
> +    }
> +  }
>   
>     return RETURN_SUCCESS;
>   }


Cancelled Event: TianoCore Design Meeting - APAC/NAMO - Friday, July 23, 2021 #cal-cancelled

devel@edk2.groups.io Calendar <noreply@...>
 

Cancelled: TianoCore Design Meeting - APAC/NAMO

This event has been cancelled.

When:
Friday, July 23, 2021
9:30am to 10:30am
(UTC+08:00) Asia/Shanghai

Where:
Microsoft Teams

Organizer: Ray Ni ray.ni@...

Description:

TOPIC

  1. NA

For more info, see here: https://www.tianocore.org/design-meeting/


Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 119 715 416 0

Alternate VTC dialing instructions

Learn More | Meeting options


[PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

Digant H Solanki
 

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3
and some fields are obsoleted in MBOX3.

Signed-off-by: Digant H Solanki <digant.h.solanki@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
---
Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)

diff --git a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 0000000000..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
@@ -0,0 +1,101 @@
+/** @file
+ IGD OpRegion definition from Intel Integrated Graphics Device OpRegion
+ Specification based on version 3.0.
+
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods
+/// Offset 0x100, Size 0x100
+///
+typedef struct {
+ UINT32 DRDY; ///< Offset 0x100 Driver Readiness
+ UINT32 CSTS; ///< Offset 0x104 Status
+ UINT32 CEVT; ///< Offset 0x108 Current Event
+ UINT8 RM11[0x14]; ///< Offset 0x10C Reserved Must be Zero
+ UINT32 DIDL[8]; ///< Offset 0x120 Supported Display Devices ID List
+ UINT32 CPDL[8]; ///< Offset 0x140 obsolete
+ UINT32 CADL[8]; ///< Offset 0x160 obsolete
+ UINT32 NADL[8]; ///< Offset 0x180 obsolete
+ UINT32 ASLP; ///< Offset 0x1A0 ASL Sleep Time Out
+ UINT32 TIDX; ///< Offset 0x1A4 obsolete
+ UINT32 CHPD; ///< Offset 0x1A8 obsolete
+ UINT32 CLID; ///< Offset 0x1AC Current Lid State Indicator
+ UINT32 CDCK; ///< Offset 0x1B0 Current Docking State Indicator
+ UINT32 SXSW; ///< Offset 0x1B4 obsolete
+ UINT32 EVTS; ///< Offset 0x1B8 obsolete
+ UINT32 CNOT; ///< Offset 0x1BC obsolete
+ UINT32 NRDY; ///< Offset 0x1C0 Driver Status
+ UINT8 DID2[0x1C]; ///< Offset 0x1C4 Extended Supported Devices ID List (DOD)
+ UINT8 CPD2[0x1C]; ///< Offset 0x1E0 obsolete
+ UINT8 RM12[4]; ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication
+/// Offset 0x200, Size 0x100
+///
+typedef struct {
+ UINT32 BCL1; ///< Offset 0x200 Backlight Brightness for LFP1
+ UINT32 BCL2; ///< Offset 0x204 Backlight Brightness for LFP2
+ UINT32 CBL1; ///< Offset 0x208 Current User Brightness Level for LFP1
+ UINT32 CBL2; ///< Offset 0x20C Current User Brightness Level for LFP2
+ UINT32 BCM1[0x1E]; ///< Offset 0x210 Backlight Brightness Levels Duty Cycle Mapping Table for LFP1
+ UINT32 BCM2[0x1E]; ///< Offset 0x288 Backlight Brightness Levels Duty Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support
+/// Offset 0x300, Size 0x100
+///
+typedef struct {
+ UINT32 ARDY; ///< Offset 0x300 obsolete
+ UINT32 ASLC; ///< Offset 0x304 obsolete
+ UINT32 TCHE; ///< Offset 0x308 obsolete
+ UINT32 ALSI; ///< Offset 0x30C obsolete
+ UINT32 BCLP; ///< Offset 0x310 obsoleted in ver 3.0, moved to Mailbox 2.
+ UINT32 PFIT; ///< Offset 0x314 obsolete
+ UINT32 CBLV; ///< Offset 0x318 obsoleted in ver 3.0, moved to Mailbox 2.
+ UINT16 BCLM[0x14]; ///< Offset 0x31C obsoleted in ver 3.0, moved to Mailbox 2.
+ UINT32 CPFM; ///< Offset 0x344 obsolete
+ UINT32 EPFM; ///< Offset 0x348 obsolete
+ UINT8 PLUT[0x4A]; ///< Offset 0x34C obsolete
+ UINT32 PFMB; ///< Offset 0x396 obsolete
+ UINT32 CCDV; ///< Offset 0x39A obsolete
+ UINT32 PCFT; ///< Offset 0x39E obsolete
+ UINT32 SROT; ///< Offset 0x3A2 obsolete
+ UINT32 IUER; ///< Offset 0x3A6 obsolete
+ UINT64 FDSS; ///< Offset 0x3AA obsolete
+ UINT32 FDSP; ///< Offset 0x3B2 obsolete
+ UINT32 STAT; ///< Offset 0x3B6 obsolete
+ UINT64 RVDA; ///< Offset 0x3BA Physical address of Raw VBT data. Added from Spec Version 0.90 to support VBT greater than 6KB.
+ UINT32 RVDS; ///< Offset 0x3C2 Size of Raw VBT data. Added from Spec Version 0.90 to support VBT greater than 6KB.
+ UINT8 VRSR; ///< Offset 0x3C6 Video RAM Self Refresh
+ UINT64 DLHP; ///< Offset 0x3C7 Dual LFP Hinge Alignment Parameters
+ UINT8 RM32[0x31]; ///< Offset 0x3CF - 0x3FF Reserved Must be zero.
+} IGD_OPREGION_MBOX3_VER_3_0;
+
+///
+/// IGD OpRegion Structure
+///
+typedef struct {
+ IGD_OPREGION_HEADER Header; ///< OpRegion header (Offset 0x0, Size 0x100)
+ IGD_OPREGION_MBOX1_VER_3_0 MBox1; ///< Mailbox 1: Public ACPI Methods (Offset 0x100, Size 0x100)
+ IGD_OPREGION_MBOX2_VER_3_0 MBox2; ///< Mailbox 2: Backlight communication (Offset 0x200, Size 0x100)
+ IGD_OPREGION_MBOX3_VER_3_0 MBox3; ///< Mailbox 3: BIOS to Driver Notification (Offset 0x300, Size 0x100)
+ IGD_OPREGION_MBOX4 MBox4; ///< Mailbox 4: Video BIOS Table (VBT) (Offset 0x400, Size 0x1800)
+ IGD_OPREGION_MBOX5 MBox5; ///< Mailbox 5: BIOS to Driver Notification Extension (Offset 0x1C00, Size 0x400)
+} IGD_OPREGION_STRUCTURE_VER_3_0;
+#pragma pack()
+
+#endif
--
2.30.2.windows.1


Re: [edk2-platform][PATCH v1 1/1] Platform/RaspberryPi/RPi4: Fix non-standard ACPI HIDs

Ard Biesheuvel
 

On Wed, 21 Jul 2021 at 22:39, Andrei Warkentin <awarkentin@vmware.com> wrote:

Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Pushed as d549e39ca1a9..194269223294

Thanks all,

________________________________
From: Ard Biesheuvel <ardb@kernel.org>
Sent: Tuesday, July 20, 2021 10:37 AM
To: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@nuviainc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Pete Batard <pete@akeo.ie>; Andrei Warkentin <awarkentin@vmware.com>; Mario Bălănică <mariobalanica02@gmail.com>
Subject: Re: [edk2-platform][PATCH v1 1/1] Platform/RaspberryPi/RPi4: Fix non-standard ACPI HIDs

On Mon, 19 Jul 2021 at 22:45, Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com> wrote:

Remove non-standard RPI ACPI _CIDs that are not needed.
This also fixes the FWTS failure reported in
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4%2Fissues%2F67&;data=04%7C01%7Cawarkentin%40vmware.com%7Cbfd9e47da54c40ef9c5408d94b51486a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637623634750321947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YO4V6pksRlNqfPlMwO0VPKNVcp4npeP%2BN%2BpigTFfZnM%3D&amp;reserved=0

The windows drivers at https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fraspberrypi%2Fwindows-drivers&;data=04%7C01%7Cawarkentin%40vmware.com%7Cbfd9e47da54c40ef9c5408d94b51486a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637623634750321947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=PMkBX%2F6vHaAoUC5tkCA7aAldaYEKFgh9w3yFYsgNrPQ%3D&amp;reserved=0
are still able to match the ACPI objects using the HIDs which
are supported in the drivers, with these two recent changes needed:
469702898789e555c6947e50216a3f79e0ddeb9
and
5c5e2742b4c983b3001c473b168b0dae2fcba0c2

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Mario Bălănică <mariobalanica02@gmail.com>
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Tested-by: Mario Bălănică <mariobalanica02@gmail.com>
Glad to see this getting cleaned up.

Anyone care to ack?


---
Platform/RaspberryPi/AcpiTables/GpuDevs.asl | 26 +++++++++++---------
Platform/RaspberryPi/AcpiTables/Sdhc.asl | 4 +--
Platform/RaspberryPi/AcpiTables/Uart.asl | 2 +-
3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
index 966a94cdb5b5..9750dc25c07c 100644
--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
@@ -13,7 +13,11 @@
Device (USB0)
{
Name (_HID, "BCM2848")
- Name (_CID, Package() { "DWC_OTG", "DWC2_OTG" })
+#if (RPI_MODEL == 3)
+ Name (_CID, "DWC_OTG")
+#elif (RPI_MODEL == 4)
+ Name (_CID, "BCM2848")
+#endif
Name (_UID, 0x0)
Name (_CCA, 0x0)
Method (_STA)
@@ -36,7 +40,7 @@ Device (USB0)
Device (GPU0)
{
Name (_HID, "BCM2850")
- Name (_CID, "VC4")
+ Name (_CID, "BCM2850")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Method (_STA)
@@ -140,7 +144,7 @@ Device (GPU0)
Device (RPIQ)
{
Name (_HID, "BCM2849")
- Name (_CID, "RPIQ")
+ Name (_CID, "BCM2849")
Name (_UID, 0)
Name (_CCA, 0x0)
Method (_STA)
@@ -164,7 +168,7 @@ Device (RPIQ)
Device (VCIQ)
{
Name (_HID, "BCM2835")
- Name (_CID, "VCIQ")
+ Name (_CID, "BCM2835")
Name (_UID, 0)
Name (_CCA, 0x0)
Name (_DEP, Package() { \_SB.GDV0.RPIQ })
@@ -189,7 +193,7 @@ Device (VCIQ)
Device (VCSM)
{
Name (_HID, "BCM2856")
- Name (_CID, "VCSM")
+ Name (_CID, "BCM2856")
Name (_UID, 0)
Name (_CCA, 0x0)
Name (_DEP, Package() { \_SB.GDV0.VCIQ })
@@ -203,7 +207,7 @@ Device (VCSM)
Device (GPI0)
{
Name (_HID, "BCM2845")
- Name (_CID, "BCMGPIO")
+ Name (_CID, "BCM2845")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Method (_STA)
@@ -230,7 +234,7 @@ Device (GPI0)
Device (I2C1)
{
Name (_HID, "BCM2841")
- Name (_CID, "BCMI2C")
+ Name (_CID, "BCM2841")
Name (_UID, 0x1)
Name (_CCA, 0x0)
Method (_STA)
@@ -254,7 +258,7 @@ Device (I2C1)
Device (I2C2)
{
Name (_HID, "BCM2841")
- Name (_CID, "BCMI2C")
+ Name (_CID, "BCM2841")
Name (_UID, 0x2)
Name (_CCA, 0x0)
Method (_STA)
@@ -278,7 +282,7 @@ Device (I2C2)
Device (SPI0)
{
Name (_HID, "BCM2838")
- Name (_CID, "BCMSPI0")
+ Name (_CID, "BCM2838")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Method (_STA)
@@ -304,7 +308,7 @@ Device (SPI0)
Device (SPI1)
{
Name (_HID, "BCM2839")
- Name (_CID, "BCMAUXSPI")
+ Name (_CID, "BCM2839")
Name (_UID, 0x1)
Name (_CCA, 0x0)
Name (_DEP, Package() { \_SB.GDV0.RPIQ })
@@ -331,7 +335,7 @@ Device (SPI1)
// Device (SPI2)
// {
// Name (_HID, "BCM2839")
-// Name (_CID, "BCMAUXSPI")
+// Name (_CID, "BCM2839")
// Name (_UID, 0x2)
// Name (_CCA, 0x0)
// Name (_DEP, Package() { \_SB.GDV0.RPIQ })
diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
index 42776e33bbc6..85d5053a338c 100644
--- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
@@ -23,7 +23,7 @@
Device (SDC1)
{
Name (_HID, "BCM2847")
- Name (_CID, "ARASAN")
+ Name (_CID, "BCM2847")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Name (_S1D, 0x1)
@@ -78,7 +78,7 @@ Device (SDC1)
Device (SDC2)
{
Name (_HID, "BCM2855")
- Name (_CID, "SDHST")
+ Name (_CID, "BCM2855")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Name (_S1D, 0x1)
diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl b/Platform/RaspberryPi/AcpiTables/Uart.asl
index 167f94e8892b..974f06d3bc3f 100644
--- a/Platform/RaspberryPi/AcpiTables/Uart.asl
+++ b/Platform/RaspberryPi/AcpiTables/Uart.asl
@@ -59,7 +59,7 @@ Device (URT0)
Device (URTM)
{
Name (_HID, "BCM2836")
- Name (_CID, "MINIUART")
+ Name (_CID, "BCM2836")
Name (_UID, 0x0)
Name (_CCA, 0x0)
Method (_STA)
--
2.25.1


Re: RFC: EXT4 filesystem driver

Marvin Häuser
 

On 22.07.21 01:12, Pedro Falcato wrote:
EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.

The Ext4Pkg implements the Simple File System Protocol for a partition
that is formatted with the EXT4 file system. This allows UEFI Drivers,
UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
on an EXT4 partition and supports booting a UEFI OS Loader from an
EXT4 partition.
This project is one of the TianoCore Google Summer of Code projects.

Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
I/O 2 Protocols, and produces the Simple File System protocol. It
allows mounting ext4 filesystems exclusively.

Brief overhead of EXT4:
Layout of an EXT2/3/4 filesystem:
(note: this driver has been developed using
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
documentation).

An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
due to the similarities) is composed of various concepts:

1) Superblock
The superblock is the structure near (1024 bytes offset from the start)
the start of the partition, and describes the filesystem in general.
Here, we get to know the size of the filesystem's blocks, which features
it supports or not, whether it's been cleanly unmounted, how many blocks
we have, etc.

2) Block groups
EXT4 filesystems are divided into block groups, and each block group covers
s_blocks_per_group(8 * Block Size) blocks. Each block group has an
associated block group descriptor; these are present directly after the
superblock. Each block group descriptor contains the location of the
inode table, and the inode and block bitmaps (note these bitmaps are only
a block long, which gets us the 8 * Block Size formula covered previously).

3) Blocks
The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
Blocks can be allocated using individual block groups's bitmaps. Note
that block 0 is invalid and its presence on extents/block tables means
it's part of a file hole, and that particular location must be read as
a block full of zeros.

4) Inodes
The ext4 filesystem divides files/directories into inodes (originally
index nodes). Each file/socket/symlink/directory/etc (here on out referred
to as a file, since there is no distinction under the ext4 filesystem) is
stored as a /nameless/ inode, that is stored in some block group's inode
table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
an old filesystem), and holds various metadata about the file. Since the
largest inode structure right now is ~160 bytes, the rest of the inode
contains inline extended attributes. Inodes' data is stored using either
data blocks (under ext2/3) or extents (under ext4).

5) Extents
Ext4 inodes store data in extents. These let N contiguous logical blocks
that are represented by N contiguous physical blocks be represented by a
single extent structure, which minimizes filesystem metadata bloat and
speeds up block mapping (particularly due to the fact that high-quality
ext4 implementations like linux's try /really/ hard to make the file
contiguous, so it's common to have files with almost 0 fragmentation).
Inodes that use extents store them in a tree, and the top of the tree
is stored on i_data. The tree's leaves always start with an
EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
block.

6) Directories
Ext4 directories are files that store name -> inode mappings for the
logical directory; this is where files get their names, which means ext4
inodes do not themselves have names, since they can be linked (present)
multiple times with different names. Directories can store entries in two
different ways:
1) Classical linear directories: They store entries as a mostly-linked
mostly-list of EXT4_DIR_ENTRY.
2) Hash tree directories: These are used for larger directories, with
hundreds of entries, and are designed in a backwards-compatible way.
These are not yet implemented in the Ext4Dxe driver.

7) Journal
Ext3/4 filesystems have a journal to help protect the filesystem against
system crashes. This is not yet implemented in Ext4Dxe but is described
in detail in the Linux kernel's documentation.

The EDK2 implementation of ext4 is based only on the public documentation
available at https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
and
the FreeBSD ext2fs driver (available at
https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs,
BSD-2-Clause-FreeBSD licensed). It is licensed as
SPDX-License-Identifier: BSD-2-Clause-Patent.

After a brief discussion with the community, the proposed package
location is edk2-platform/Features/Ext4Pkg
(relevant discussion: https://edk2.groups.io/g/devel/topic/83060185).

I was the main contributor and I would like to maintain the package in
the future, if possible.
While I personally don't like it's outside of the EDK II core, I kind of get it. However I would strongly suggest to choose a more general package name, like "LinuxFsPkg", or "NixFsPkg", or maybe even just "FileSystemPkg" (and move FAT over some day?). Imagine someone wants to import BTRFS next year, should it really be "BtrfsPkg"? I understand it follows the "FatPkg" convention, but I feel like people forget FatPkg was special as to its awkward license before Microsoft allowed a change a few years ago. Maintainers.txt already has the concept of different Reviewers per subfolder, maybe it could be extended a little to have a common EDK II contributor to officially maintain the package, but have you be a Maintainer or something like a Reviewer+ to your driver? Or you could maintain the entire package of course.

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.
I may be alone, but I strongly object. One of our projects (OpenCore) has a disgusting way of writing files because the FAT32 driver in Aptio IV firmwares may corrupt the filesystem when resizing files. To be honest, it may corrupt with other usages too and we never noticed, because basically we wrote the code to require the least amount of (complex) FS operations.

The issue with EDK II is, there is a lot of own code and a lot of users, but little testing. By that I do not mean that developers do not test their code, but that nobody sits down and performs all sorts of FS manipulations in all sorts of orders and closely observes the result for regression-testing. Users will not really test it either, as UEFI to them should just somehow boot to Windows. If at least the code was shared with a codebase that is known-trusted (e.g. the Linux kernel itself), that'd be much easier to trust, but realistically this is not going to happen.
My point is, if a company like AMI cannot guarantee writing does not damage the FS for a very simple FS, how do you plan to guarantee yours doesn't for a much more complex FS? I'd rather have only one simple FS type that supports writing for most use-cases (e.g. logging).

At the very least I would beg you to have a PCD to turn write support off - if it will be off by default, that'd be great of course. :)
Was there any discussion yet as to why write support is needed in the first place you could point me to?

Thanks for your work!

Best regards,
Marvin

The driver's handling of unclean unmounting through forced shutdown is unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato




Re: [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

Ard Biesheuvel
 



On Wed, 21 Jul 2021 at 20:04, Kinney, Michael D <michael.d.kinney@...> wrote:

Hi Jeff,

 

I see.  I missed the file rename line in the git patch.

 

I think the description needs to be expanded to clearly describe the production and consumption of this device path with this GUID.

 

  1. What component creates the UEFI handle with the Device Path Protocol and the LoadFile2 Protocol with the initrd image?  Is it the platform FW or the OS Loader?  If it is the platform FW, then how does the platform FW know which initrd image to publish if there are multiple Linux OSes installed?

This is really the firmware/loader's problem. In the ARM / RISC-V world, the distinction between firmware and pre-OS loader is not as clear cut, and for instance, U-boot in EFI mode can either boot the kernel directly (and expose the initrd via this method), or invoke GRUB as an EFI app using LoadImage/StartImage, in which case GRUB can load the kernel and/or initrd via whichever interface it desires.

It is therefore also the platform FW's problem to decide which initrd goes with which kernel - it is highly platform dependent whether a certain initrd is compatible with only a single kernel, or can be combined with any kernel (e.g., when the kernel has all drivers builtin, and the initrd only contains the user space)
 
  1. What component locates the UEFI handle with the Device Path Protocol and the LoadFile2 Protocol with the initrd image?  It is another stage of the OS Loader or the OS Kernel?  Given that these handles are only available before ExitBootServices, I think this means that the component that locates the initrd image has to do so before ExitBootServices is called.

 


The consumer of the protocol is the EFI stub loader in Linux, i.e., the OS loader that is built into the OS kernel. It is the agent that calls ExitBootServices(), and it indeed consumes the protocol beforehand.

In summary, I think it should be sufficient to describe the consumer's expectations with respect to the API. I don't think it makes sense to be normative about how platform firmware or intermediate loaders keep track of which file to expose, as long as it complies with the consumer's requirements.

 

To: Kinney, Michael D <michael.d.kinney@...>; Ard Biesheuvel <ardb@...>
Cc: devel@edk2.groups.io; ardb+tianocore@...; Justen, Jordan L <jordan.l.justen@...>; gaoliming@...; Liu, Zhiguang <zhiguang.liu@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

 

Does this look good for text to add

 

"Linux distro boot generally relies on an initial ramdisk (initrd)
which is provided by the loader, and which contains additional kernel
modules (for storage and network, for instance), and the initial user
space startup code, i.e., the code which brings up the user space side
of the entire OS.

In order to provide a standard method to locate this file,

the GUID defined in this file is used to describe the device path

for a LoadFile2 Protocol instance that is responsible for loading the initrd file"

 

 

Also, the patch does have

 {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
 3 files changed, 5 insertions(+), 1 deletion(-)
 rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
[snip]
diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
similarity index 100%
rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h

 

 

Thanks,

Jeff


From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, July 21, 2021 9:38 AM
To: Jeff Brasen <jbrasen@...>; Ard Biesheuvel <ardb@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; ardb+tianocore@... <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; gaoliming@... <gaoliming@...>; Liu, Zhiguang <zhiguang.liu@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

 

External email: Use caution opening links or attachments

 

Hi Ard,

 

If this device path node is considered as part of the standard interface between the Linux kernel and

firmware, then it does make sense for it to be in the MdePkg.  We usually try to reference a public

specification in the include file that defines the interface.

 

In this case, since there is no public document, but it is part of the Linux kernel assumptions,

can the include file for the GUID provide pointers to the Linux kernel that uses the GUID and

describe how the GUID is produced by the FW and consumed by the Linux kernel?

 

I also see that this patch appears to be incomplete.  There is an OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h

file in the OvmfPkg.  Shouldn’t that file also be moved to the MdePkg as part of this patch?

 

Thanks,

 

Mike

 

From: Jeff Brasen <jbrasen@...>
Sent: Tuesday, July 20, 2021 9:59 AM
To: Ard Biesheuvel <ardb@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: devel@edk2.groups.io; ardb+tianocore@...; Justen, Jordan L <jordan.l.justen@...>; gaoliming@...; Liu, Zhiguang <zhiguang.liu@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

 

In my opinion MdePkg is where this should be as it is meant to be used by multiple software entities (linux kernel, grub, edk2, coreboot w/ uefi binding) and probably should be documented in some spec (Although, I am not sure which one would make sense)

 

I am fine with MdeModulePkg as well though.

 

Thanks,

Jeff


From: Ard Biesheuvel <ardb@...>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney@...>
Cc: Jeff Brasen <jbrasen@...>; devel@edk2.groups.io <devel@edk2.groups.io>; ardb+tianocore@... <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; gaoliming@... <gaoliming@...>; Liu, Zhiguang <zhiguang.liu@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

 

External email: Use caution opening links or attachments


On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@...> wrote:
>
> Hi Ard,
>
> I see you were involved in the OS side changes.
>
> Can you explain what is required for the FW <-> OS interface with respect to Load File Protocol and this media device path node.
>
> What happens if this media device path node is not present?  What breaks?
>
> Trying to figure out if this is a required interop feature (MdePkg candidate) or an EDK II specific extension (MdeModulePkg candidate).
>

Let me give some context first:

Linux distro boot generally relies on an initial ramdisk (initrd)
which is provided by the loader, and which contains additional kernel
modules (for storage and netwerk, for instance), and the initial user
space startup code, ie., the code which brings up the user space side
of the entire OS.

Before we introduced this media path, the only way for a EFI pre-OS
loader (such as GRUB) to provide this initrd was to copy it into DRAM
somewhere, and use a arch-specific method of passing the DRAM address
and size to the OS (x86 uses struct bootparam, whereas ARM uses device
tree). It also requires knowledge on the part of GRUB regarding which
parts of DRAM are suitable for holding an initrd image. For measured
boot scenarios, it may be an advantage not to have the initrd linger
in DRAM for longer that necessary, and we actually intend to measure
the initrd loaded via the new method right after it has been loaded
this way.

To avoid extending this to other architectures such as RISC-V, I
decided to introduce a special vendor media path for Linux initrd
images, which GRUB et al can implement, which provides the initrd
image when the OS loader that consumes it asks for it.

So for Linux on x86 or ARM, this is optional, given that support for
the old method is not going away any time soon. For RISC-V, I
suggested that only the new method be implemented, but I am not sure
what the status is there. Note that many embedded style systems don't
use GRUB, and may not use initrds to begin with. OTOH, U-Boot also
implements support for the Linux initrd vendor media path, and work is
ongoing to add measured boot support as well.

In any case, I don't have a strong preference where this should live,
as long as it is in a generic place where all architectures can use
it.

--
Ard.


Re: [PATCH v4 10/11] OvmfPkg: add BlobVerifierLibSevHashes

Dov Murik
 

Here's the diff from the v3 of this patch. It's supposed to catch
more cases of bad length fields overflowing the reserved MEMFD space or
the declared length of the table.



diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
index 797d63d18067..372ae6f469e7 100644
--- a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
@@ -94,7 +94,7 @@ VerifyBlob (
)
{
CONST GUID *Guid;
- INT32 Len;
+ INT32 Remaining;
HASH_TABLE *Entry;

if (mHashesTable == NULL || mHashesTableSize == 0) {
@@ -111,9 +111,13 @@ VerifyBlob (
return EFI_ACCESS_DENIED;
}

- for (Entry = mHashesTable, Len = 0;
- Len < (INT32)mHashesTableSize;
- Len += Entry->Len,
+ //
+ // Remaining is INT32 to catch underflow in case Entry->Len has a
+ // very high UINT16 value
+ //
+ for (Entry = mHashesTable, Remaining = mHashesTableSize;
+ Remaining >= sizeof *Entry && Remaining >= Entry->Len;
+ Remaining -= Entry->Len,
Entry = (HASH_TABLE *)((UINT8 *)Entry + Entry->Len)) {
UINTN EntrySize;
EFI_STATUS Status;
@@ -125,7 +129,7 @@ VerifyBlob (

DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __FUNCTION__,
Guid));

- EntrySize = Entry->Len - sizeof (Entry->Guid) - sizeof (Entry->Len);
+ EntrySize = Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;
if (EntrySize != SHA256_DIGEST_SIZE) {
DEBUG ((DEBUG_ERROR, "%a: Hash has the wrong size %d != %d\n",
__FUNCTION__, EntrySize, SHA256_DIGEST_SIZE));
@@ -161,7 +165,8 @@ VerifyBlob (
This function always returns success, even if the table can't be
found. The
subsequent VerifyBlob calls will fail if no table was found.

- @retval RETURN_SUCCESS The verifier tables were set up correctly
+ @retval RETURN_SUCCESS The hashes table is set up correctly, or
there is no
+ hashes table
**/
RETURN_STATUS
EFIAPI
@@ -175,15 +180,9 @@ BlobVerifierLibSevHashesConstructor (
mHashesTable = NULL;
mHashesTableSize = 0;

- if (Ptr == NULL || Size == 0) {
- return RETURN_SUCCESS;
- }
-
- if (!CompareGuid (&Ptr->Guid, &SEV_HASH_TABLE_GUID)) {
- return RETURN_SUCCESS;
- }
-
- if (Ptr->Len < (sizeof Ptr->Guid + sizeof Ptr->Len)) {
+ if (Ptr == NULL || Size < sizeof *Ptr ||
+ !CompareGuid (&Ptr->Guid, &SEV_HASH_TABLE_GUID) ||
+ Ptr->Len < sizeof *Ptr || Ptr->Len > Size) {
return RETURN_SUCCESS;
}

On 22/07/2021 11:43, Dov Murik wrote:
Add an implementation for BlobVerifierLib that locates the SEV hashes
table and verifies that the calculated hashes of the kernel, initrd, and
cmdline blobs indeed match the expected hashes stated in the hashes
table.

If there's a missing hash or a hash mismatch then EFI_ACCESS_DENIED is
returned which will cause a failure to load a kernel image.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Co-developed-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf | 37 ++++
OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c | 199 ++++++++++++++++++++
2 files changed, 236 insertions(+)

diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
new file mode 100644
index 000000000000..76ca0b8154ce
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
@@ -0,0 +1,37 @@
+## @file

+#

+# Blob verifier library that uses SEV hashes table. The hashes table holds the

+# allowed hashes of the kernel, initrd, and cmdline blobs.

+#

+# Copyright (C) 2021, IBM Corp

+#

+# SPDX-License-Identifier: BSD-2-Clause-Patent

+#

+##

+

+[Defines]

+ INF_VERSION = 1.29

+ BASE_NAME = BlobVerifierLibSevHashes

+ FILE_GUID = 59e713b5-eff3-46a7-8d8b-46f4c004ad7b

+ MODULE_TYPE = BASE

+ VERSION_STRING = 1.0

+ LIBRARY_CLASS = BlobVerifierLib

+ CONSTRUCTOR = BlobVerifierLibSevHashesConstructor

+

+[Sources]

+ BlobVerifierSevHashes.c

+

+[Packages]

+ CryptoPkg/CryptoPkg.dec

+ MdePkg/MdePkg.dec

+ OvmfPkg/OvmfPkg.dec

+

+[LibraryClasses]

+ BaseCryptLib

+ BaseMemoryLib

+ DebugLib

+ PcdLib

+

+[FixedPcd]

+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase

+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize

diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
new file mode 100644
index 000000000000..372ae6f469e7
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
@@ -0,0 +1,199 @@
+/** @file

+

+ Blob verifier library that uses SEV hashes table. The hashes table holds the

+ allowed hashes of the kernel, initrd, and cmdline blobs.

+

+ Copyright (C) 2021, IBM Corporation

+

+ SPDX-License-Identifier: BSD-2-Clause-Patent

+**/

+

+#include <Library/BaseCryptLib.h>

+#include <Library/BaseLib.h>

+#include <Library/BaseMemoryLib.h>

+#include <Library/DebugLib.h>

+#include <Library/BlobVerifierLib.h>

+

+/**

+ The SEV Hashes table must be in encrypted memory and has the table

+ and its entries described by

+

+ <GUID>|UINT16 <len>|<data>

+

+ With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21

+

+ The current possible table entries are for the kernel, the initrd

+ and the cmdline:

+

+ 4de79437-abd2-427f-b835-d5b172d2045b kernel

+ 44baf731-3a2f-4bd7-9af1-41e29169781d initrd

+ 97d02dd8-bd20-4c94-aa78-e7714d36ab2a cmdline

+

+ The size of the entry is used to identify the hash, but the

+ expectation is that it will be 32 bytes of SHA-256.

+**/

+

+#define SEV_HASH_TABLE_GUID \

+ (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 0x11, 0xfd, 0x21 } }

+#define SEV_KERNEL_HASH_GUID \

+ (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 0xd2, 0x04, 0x5b } }

+#define SEV_INITRD_HASH_GUID \

+ (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 0x69, 0x78, 0x1d } }

+#define SEV_CMDLINE_HASH_GUID \

+ (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 0x36, 0xab, 0x2a } }

+

+STATIC CONST EFI_GUID mSevKernelHashGuid = SEV_KERNEL_HASH_GUID;

+STATIC CONST EFI_GUID mSevInitrdHashGuid = SEV_INITRD_HASH_GUID;

+STATIC CONST EFI_GUID mSevCmdlineHashGuid = SEV_CMDLINE_HASH_GUID;

+

+#pragma pack (1)

+typedef struct {

+ GUID Guid;

+ UINT16 Len;

+ UINT8 Data[];

+} HASH_TABLE;

+#pragma pack ()

+

+STATIC HASH_TABLE *mHashesTable;

+STATIC UINT16 mHashesTableSize;

+

+STATIC

+CONST GUID*

+FindBlobEntryGuid (

+ IN CONST CHAR16 *BlobName

+ )

+{

+ if (StrCmp (BlobName, L"kernel") == 0) {

+ return &mSevKernelHashGuid;

+ } else if (StrCmp (BlobName, L"initrd") == 0) {

+ return &mSevInitrdHashGuid;

+ } else if (StrCmp (BlobName, L"cmdline") == 0) {

+ return &mSevCmdlineHashGuid;

+ } else {

+ return NULL;

+ }

+}

+

+/**

+ Verify blob from an external source.

+

+ @param[in] BlobName The name of the blob

+ @param[in] Buf The data of the blob

+ @param[in] BufSize The size of the blob in bytes

+

+ @retval EFI_SUCCESS The blob was verified successfully.

+ @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore

+ should be considered non-secure.

+**/

+EFI_STATUS

+EFIAPI

+VerifyBlob (

+ IN CONST CHAR16 *BlobName,

+ IN CONST VOID *Buf,

+ IN UINT32 BufSize

+ )

+{

+ CONST GUID *Guid;

+ INT32 Remaining;

+ HASH_TABLE *Entry;

+

+ if (mHashesTable == NULL || mHashesTableSize == 0) {

+ DEBUG ((DEBUG_ERROR,

+ "%a: Verifier called but no hashes table discoverd in MEMFD\n",

+ __FUNCTION__));

+ return EFI_ACCESS_DENIED;

+ }

+

+ Guid = FindBlobEntryGuid (BlobName);

+ if (Guid == NULL) {

+ DEBUG ((DEBUG_ERROR, "%a: Unknown blob name \"%s\"\n", __FUNCTION__,

+ BlobName));

+ return EFI_ACCESS_DENIED;

+ }

+

+ //

+ // Remaining is INT32 to catch underflow in case Entry->Len has a

+ // very high UINT16 value

+ //

+ for (Entry = mHashesTable, Remaining = mHashesTableSize;

+ Remaining >= sizeof *Entry && Remaining >= Entry->Len;

+ Remaining -= Entry->Len,

+ Entry = (HASH_TABLE *)((UINT8 *)Entry + Entry->Len)) {

+ UINTN EntrySize;

+ EFI_STATUS Status;

+ UINT8 Hash[SHA256_DIGEST_SIZE];

+

+ if (!CompareGuid (&Entry->Guid, Guid)) {

+ continue;

+ }

+

+ DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __FUNCTION__, Guid));

+

+ EntrySize = Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;

+ if (EntrySize != SHA256_DIGEST_SIZE) {

+ DEBUG ((DEBUG_ERROR, "%a: Hash has the wrong size %d != %d\n",

+ __FUNCTION__, EntrySize, SHA256_DIGEST_SIZE));

+ return EFI_ACCESS_DENIED;

+ }

+

+ //

+ // Calculate the buffer's hash and verify that it is identical to the

+ // expected hash table entry

+ //

+ Sha256HashAll (Buf, BufSize, Hash);

+

+ if (CompareMem (Entry->Data, Hash, EntrySize) == 0) {

+ Status = EFI_SUCCESS;

+ DEBUG ((DEBUG_INFO, "%a: Hash comparison succeeded for \"%s\"\n",

+ __FUNCTION__, BlobName));

+ } else {

+ Status = EFI_ACCESS_DENIED;

+ DEBUG ((DEBUG_ERROR, "%a: Hash comparison failed for \"%s\"\n",

+ __FUNCTION__, BlobName));

+ }

+ return Status;

+ }

+

+ DEBUG ((DEBUG_ERROR, "%a: Hash GUID %g not found in table\n", __FUNCTION__,

+ Guid));

+ return EFI_ACCESS_DENIED;

+}

+

+/**

+ Locate the SEV hashes table.

+

+ This function always returns success, even if the table can't be found. The

+ subsequent VerifyBlob calls will fail if no table was found.

+

+ @retval RETURN_SUCCESS The hashes table is set up correctly, or there is no

+ hashes table

+**/

+RETURN_STATUS

+EFIAPI

+BlobVerifierLibSevHashesConstructor (

+ VOID

+ )

+{

+ HASH_TABLE *Ptr = (void *)(UINTN)FixedPcdGet64 (PcdQemuHashTableBase);

+ UINT32 Size = FixedPcdGet32 (PcdQemuHashTableSize);

+

+ mHashesTable = NULL;

+ mHashesTableSize = 0;

+

+ if (Ptr == NULL || Size < sizeof *Ptr ||

+ !CompareGuid (&Ptr->Guid, &SEV_HASH_TABLE_GUID) ||

+ Ptr->Len < sizeof *Ptr || Ptr->Len > Size) {

+ return RETURN_SUCCESS;

+ }

+

+ DEBUG ((DEBUG_INFO, "%a: Found injected hashes table in secure location\n",

+ __FUNCTION__));

+

+ mHashesTable = (HASH_TABLE *)Ptr->Data;

+ mHashesTableSize = Ptr->Len - sizeof Ptr->Guid - sizeof Ptr->Len;

+

+ DEBUG ((DEBUG_VERBOSE, "%a: mHashesTable=0x%p, Size=%u\n", __FUNCTION__,

+ mHashesTable, mHashesTableSize));

+

+ return RETURN_SUCCESS;

+}


[PATCH v4 02/11] OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds

Dov Murik
 

Newer kernels support efistub and therefore don't need all the legacy
stuff in X86QemuLoadImageLib, which are harder to secure. Specifically
the verification of kernel/initrd/cmdline blobs will be added only to
the GenericQemuLoadImageLib implementation, so use that for SEV builds.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 1d487befae08..a2f1324c40a6 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -368,7 +368,7 @@ [LibraryClasses.common.DXE_DRIVER]
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf=0D
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf=0D
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf=
=0D
- QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib=
.inf=0D
+ QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoad=
ImageLib.inf=0D
!if $(TPM_ENABLE) =3D=3D TRUE=0D
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.i=
nf=0D
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.in=
f=0D
--=20
2.25.1


[PATCH v4 10/11] OvmfPkg: add BlobVerifierLibSevHashes

Dov Murik
 

Add an implementation for BlobVerifierLib that locates the SEV hashes
table and verifies that the calculated hashes of the kernel, initrd, and
cmdline blobs indeed match the expected hashes stated in the hashes
table.

If there's a missing hash or a hash mismatch then EFI_ACCESS_DENIED is
returned which will cause a failure to load a kernel image.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Co-developed-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf | 37 ++++
OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c | 199 +++++++=
+++++++++++++
2 files changed, 236 insertions(+)

diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf b=
/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
new file mode 100644
index 000000000000..76ca0b8154ce
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
@@ -0,0 +1,37 @@
+## @file=0D
+#=0D
+# Blob verifier library that uses SEV hashes table. The hashes table hol=
ds the=0D
+# allowed hashes of the kernel, initrd, and cmdline blobs.=0D
+#=0D
+# Copyright (C) 2021, IBM Corp=0D
+#=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 1.29=0D
+ BASE_NAME =3D BlobVerifierLibSevHashes=0D
+ FILE_GUID =3D 59e713b5-eff3-46a7-8d8b-46f4c004ad7b=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D BlobVerifierLib=0D
+ CONSTRUCTOR =3D BlobVerifierLibSevHashesConstructor=0D
+=0D
+[Sources]=0D
+ BlobVerifierSevHashes.c=0D
+=0D
+[Packages]=0D
+ CryptoPkg/CryptoPkg.dec=0D
+ MdePkg/MdePkg.dec=0D
+ OvmfPkg/OvmfPkg.dec=0D
+=0D
+[LibraryClasses]=0D
+ BaseCryptLib=0D
+ BaseMemoryLib=0D
+ DebugLib=0D
+ PcdLib=0D
+=0D
+[FixedPcd]=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize=0D
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c b/Ovmf=
Pkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
new file mode 100644
index 000000000000..372ae6f469e7
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
@@ -0,0 +1,199 @@
+/** @file=0D
+=0D
+ Blob verifier library that uses SEV hashes table. The hashes table hold=
s the=0D
+ allowed hashes of the kernel, initrd, and cmdline blobs.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#include <Library/BaseCryptLib.h>=0D
+#include <Library/BaseLib.h>=0D
+#include <Library/BaseMemoryLib.h>=0D
+#include <Library/DebugLib.h>=0D
+#include <Library/BlobVerifierLib.h>=0D
+=0D
+/**=0D
+ The SEV Hashes table must be in encrypted memory and has the table=0D
+ and its entries described by=0D
+=0D
+ <GUID>|UINT16 <len>|<data>=0D
+=0D
+ With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21=0D
+=0D
+ The current possible table entries are for the kernel, the initrd=0D
+ and the cmdline:=0D
+=0D
+ 4de79437-abd2-427f-b835-d5b172d2045b kernel=0D
+ 44baf731-3a2f-4bd7-9af1-41e29169781d initrd=0D
+ 97d02dd8-bd20-4c94-aa78-e7714d36ab2a cmdline=0D
+=0D
+ The size of the entry is used to identify the hash, but the=0D
+ expectation is that it will be 32 bytes of SHA-256.=0D
+**/=0D
+=0D
+#define SEV_HASH_TABLE_GUID \=0D
+ (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 0x1=
1, 0xfd, 0x21 } }=0D
+#define SEV_KERNEL_HASH_GUID \=0D
+ (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 0xd=
2, 0x04, 0x5b } }=0D
+#define SEV_INITRD_HASH_GUID \=0D
+ (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 0x6=
9, 0x78, 0x1d } }=0D
+#define SEV_CMDLINE_HASH_GUID \=0D
+ (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 0x3=
6, 0xab, 0x2a } }=0D
+=0D
+STATIC CONST EFI_GUID mSevKernelHashGuid =3D SEV_KERNEL_HASH_GUID;=0D
+STATIC CONST EFI_GUID mSevInitrdHashGuid =3D SEV_INITRD_HASH_GUID;=0D
+STATIC CONST EFI_GUID mSevCmdlineHashGuid =3D SEV_CMDLINE_HASH_GUID;=0D
+=0D
+#pragma pack (1)=0D
+typedef struct {=0D
+ GUID Guid;=0D
+ UINT16 Len;=0D
+ UINT8 Data[];=0D
+} HASH_TABLE;=0D
+#pragma pack ()=0D
+=0D
+STATIC HASH_TABLE *mHashesTable;=0D
+STATIC UINT16 mHashesTableSize;=0D
+=0D
+STATIC=0D
+CONST GUID*=0D
+FindBlobEntryGuid (=0D
+ IN CONST CHAR16 *BlobName=0D
+ )=0D
+{=0D
+ if (StrCmp (BlobName, L"kernel") =3D=3D 0) {=0D
+ return &mSevKernelHashGuid;=0D
+ } else if (StrCmp (BlobName, L"initrd") =3D=3D 0) {=0D
+ return &mSevInitrdHashGuid;=0D
+ } else if (StrCmp (BlobName, L"cmdline") =3D=3D 0) {=0D
+ return &mSevCmdlineHashGuid;=0D
+ } else {=0D
+ return NULL;=0D
+ }=0D
+}=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ )=0D
+{=0D
+ CONST GUID *Guid;=0D
+ INT32 Remaining;=0D
+ HASH_TABLE *Entry;=0D
+=0D
+ if (mHashesTable =3D=3D NULL || mHashesTableSize =3D=3D 0) {=0D
+ DEBUG ((DEBUG_ERROR,=0D
+ "%a: Verifier called but no hashes table discoverd in MEMFD\n",=0D
+ __FUNCTION__));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ Guid =3D FindBlobEntryGuid (BlobName);=0D
+ if (Guid =3D=3D NULL) {=0D
+ DEBUG ((DEBUG_ERROR, "%a: Unknown blob name \"%s\"\n", __FUNCTION__,=0D
+ BlobName));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ //=0D
+ // Remaining is INT32 to catch underflow in case Entry->Len has a=0D
+ // very high UINT16 value=0D
+ //=0D
+ for (Entry =3D mHashesTable, Remaining =3D mHashesTableSize;=0D
+ Remaining >=3D sizeof *Entry && Remaining >=3D Entry->Len;=0D
+ Remaining -=3D Entry->Len,=0D
+ Entry =3D (HASH_TABLE *)((UINT8 *)Entry + Entry->Len)) {=0D
+ UINTN EntrySize;=0D
+ EFI_STATUS Status;=0D
+ UINT8 Hash[SHA256_DIGEST_SIZE];=0D
+=0D
+ if (!CompareGuid (&Entry->Guid, Guid)) {=0D
+ continue;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __FUNCTION__, Guid=
));=0D
+=0D
+ EntrySize =3D Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;=0D
+ if (EntrySize !=3D SHA256_DIGEST_SIZE) {=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash has the wrong size %d !=3D %d\n",=0D
+ __FUNCTION__, EntrySize, SHA256_DIGEST_SIZE));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ //=0D
+ // Calculate the buffer's hash and verify that it is identical to the=
=0D
+ // expected hash table entry=0D
+ //=0D
+ Sha256HashAll (Buf, BufSize, Hash);=0D
+=0D
+ if (CompareMem (Entry->Data, Hash, EntrySize) =3D=3D 0) {=0D
+ Status =3D EFI_SUCCESS;=0D
+ DEBUG ((DEBUG_INFO, "%a: Hash comparison succeeded for \"%s\"\n",=0D
+ __FUNCTION__, BlobName));=0D
+ } else {=0D
+ Status =3D EFI_ACCESS_DENIED;=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash comparison failed for \"%s\"\n",=0D
+ __FUNCTION__, BlobName));=0D
+ }=0D
+ return Status;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash GUID %g not found in table\n", __FUNCTION=
__,=0D
+ Guid));=0D
+ return EFI_ACCESS_DENIED;=0D
+}=0D
+=0D
+/**=0D
+ Locate the SEV hashes table.=0D
+=0D
+ This function always returns success, even if the table can't be found. =
The=0D
+ subsequent VerifyBlob calls will fail if no table was found.=0D
+=0D
+ @retval RETURN_SUCCESS The hashes table is set up correctly, or there =
is no=0D
+ hashes table=0D
+**/=0D
+RETURN_STATUS=0D
+EFIAPI=0D
+BlobVerifierLibSevHashesConstructor (=0D
+ VOID=0D
+ )=0D
+{=0D
+ HASH_TABLE *Ptr =3D (void *)(UINTN)FixedPcdGet64 (PcdQemuHashTableBase);=
=0D
+ UINT32 Size =3D FixedPcdGet32 (PcdQemuHashTableSize);=0D
+=0D
+ mHashesTable =3D NULL;=0D
+ mHashesTableSize =3D 0;=0D
+=0D
+ if (Ptr =3D=3D NULL || Size < sizeof *Ptr ||=0D
+ !CompareGuid (&Ptr->Guid, &SEV_HASH_TABLE_GUID) ||=0D
+ Ptr->Len < sizeof *Ptr || Ptr->Len > Size) {=0D
+ return RETURN_SUCCESS;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_INFO, "%a: Found injected hashes table in secure location\=
n",=0D
+ __FUNCTION__));=0D
+=0D
+ mHashesTable =3D (HASH_TABLE *)Ptr->Data;=0D
+ mHashesTableSize =3D Ptr->Len - sizeof Ptr->Guid - sizeof Ptr->Len;=0D
+=0D
+ DEBUG ((DEBUG_VERBOSE, "%a: mHashesTable=3D0x%p, Size=3D%u\n", __FUNCTIO=
N__,=0D
+ mHashesTable, mHashesTableSize));=0D
+=0D
+ return RETURN_SUCCESS;=0D
+}=0D
--=20
2.25.1


[PATCH v4 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation

Dov Murik
 

BlobVerifierLib will be used to verify blobs fetching them from QEMU's
firmware config (fw_cfg) in platforms that enable such verification.

The null implementation BlobVerifierLibNull treats all blobs as valid.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/OvmfPkg.dec | 3 ++
OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf | 24 +++++++++++++
OvmfPkg/Include/Library/BlobVerifierLib.h | 38 +++++++++++++=
+++++++
OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c | 33 +++++++++++++=
++++
4 files changed, 98 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6ae733f6e39f..f82228d69cc2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -23,6 +23,9 @@ [LibraryClasses]
## @libraryclass Access bhyve's firmware control interface.=0D
BhyveFwCtlLib|Include/Library/BhyveFwCtlLib.h=0D
=0D
+ ## @libraryclass Verify blobs read from the VMM=0D
+ BlobVerifierLib|Include/Library/BlobVerifierLib.h=0D
+=0D
## @libraryclass Loads and boots a Linux kernel image=0D
#=0D
LoadLinuxLib|Include/Library/LoadLinuxLib.h=0D
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf b/Ovmf=
Pkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
new file mode 100644
index 000000000000..850d398e65a4
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
@@ -0,0 +1,24 @@
+## @file=0D
+#=0D
+# Null implementation of the blob verifier library.=0D
+#=0D
+# Copyright (C) 2021, IBM Corp=0D
+#=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 1.29=0D
+ BASE_NAME =3D BlobVerifierLibNull=0D
+ FILE_GUID =3D b1b5533e-e01a-43bb-9e54-414f00ca036e=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D BlobVerifierLib=0D
+=0D
+[Sources]=0D
+ BlobVerifierNull.c=0D
+=0D
+[Packages]=0D
+ MdePkg/MdePkg.dec=0D
+ OvmfPkg/OvmfPkg.dec=0D
diff --git a/OvmfPkg/Include/Library/BlobVerifierLib.h b/OvmfPkg/Include/Li=
brary/BlobVerifierLib.h
new file mode 100644
index 000000000000..db122684f76c
--- /dev/null
+++ b/OvmfPkg/Include/Library/BlobVerifierLib.h
@@ -0,0 +1,38 @@
+/** @file=0D
+=0D
+ Blob verification library=0D
+=0D
+ This library class allows verifiying whether blobs from external sources=
=0D
+ (such as QEMU's firmware config) are trusted.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#ifndef BLOB_VERIFIER_LIB_H__=0D
+#define BLOB_VERIFIER_LIB_H__=0D
+=0D
+#include <Uefi/UefiBaseType.h>=0D
+#include <Base.h>=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ );=0D
+=0D
+#endif=0D
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c b/OvmfPkg/L=
ibrary/BlobVerifierLib/BlobVerifierNull.c
new file mode 100644
index 000000000000..975d4dd52f80
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c
@@ -0,0 +1,33 @@
+/** @file=0D
+=0D
+ Null implementation of the blob verifier library.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#include <Library/BaseLib.h>=0D
+#include <Library/BlobVerifierLib.h>=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ )=0D
+{=0D
+ return EFI_SUCCESS;=0D
+}=0D
--=20
2.25.1


[PATCH v4 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

Dov Murik
 

In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce
verification of hashes of the kernel/initrd/cmdline blobs fetched from
firmware config.

This allows for secure (measured) boot of SEV guests with QEMU's
-kernel/-initrd/-append switches (with the corresponding QEMU support
for injecting the hashes table into initial measured guest memory).

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index b2cc96cc5a97..c01599ea354f 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -173,7 +173,7 @@ [LibraryClasses]
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf=0D
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customize=
dDisplayLib.inf=0D
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltL=
ib.inf=0D
- BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf=
=0D
+ BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes=
.inf=0D
=0D
!if $(SOURCE_DEBUG_ENABLE) =3D=3D TRUE=0D
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDeb=
ug/PeCoffExtraActionLibDebug.inf=0D
@@ -696,7 +696,7 @@ [Components]
}=0D
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
<LibraryClasses>=0D
- NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf=0D
+ NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf=0D
}=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
--=20
2.25.1


[PATCH v4 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg

Dov Murik
 

From: James Bottomley <jejb@linux.ibm.com>

Support QEMU's -kernel option.

Create a QemuKernel.c for PlatformBootManagerLibGrub
which is an exact copy of the file
PlatformBootManagerLib/QemuKernel.c .

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc =
| 1 +
OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf =
| 2 ++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h =
| 11 +++++++++++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c =
| 5 +++++
OvmfPkg/Library/{PlatformBootManagerLib =3D> PlatformBootManagerLibGrub}/Q=
emuKernel.c | 0
5 files changed, 19 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a2f1324c40a6..aefdcf881c99 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -281,6 +281,7 @@ [LibraryClasses.common.PEIM]
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuE=
xceptionHandlerLib.inf=0D
MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf=0D
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf=
=0D
+ QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoad=
ImageLib.inf=0D
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf=0D
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf=0D
=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManager=
LibGrub.inf b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManage=
rLibGrub.inf
index 9a806d17ec45..5f6f73d18470 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub=
.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub=
.inf
@@ -23,6 +23,7 @@ [Defines]
=0D
[Sources]=0D
BdsPlatform.c=0D
+ QemuKernel.c=0D
PlatformData.c=0D
BdsPlatform.h=0D
=0D
@@ -46,6 +47,7 @@ [LibraryClasses]
BootLogoLib=0D
DevicePathLib=0D
PciLib=0D
+ QemuLoadImageLib=0D
UefiLib=0D
PlatformBmPrintScLib=0D
Tcg2PhysicalPresenceLib=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h b/Ovm=
fPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
index 748c63081920..f1d3a2906c00 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
@@ -172,4 +172,15 @@ PlatformInitializeConsole (
IN PLATFORM_CONSOLE_CONNECT_ENTRY *PlatformConsole=0D
);=0D
=0D
+/**=0D
+ Loads and boots UEFI Linux via the FwCfg interface.=0D
+=0D
+ @retval EFI_NOT_FOUND - The Linux kernel was not found=0D
+=0D
+**/=0D
+EFI_STATUS=0D
+TryRunningQemuKernel (=0D
+ VOID=0D
+ );=0D
+=0D
#endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c b/Ovm=
fPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
index 5c92d4fc2b09..7cceeea4879c 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
@@ -1315,6 +1315,11 @@ PlatformBootManagerAfterConsole (
//=0D
Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
=0D
+ //=0D
+ // Process QEMU's -kernel command line option=0D
+ //=0D
+ TryRunningQemuKernel ();=0D
+=0D
//=0D
// Perform some platform specific connect sequence=0D
//=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c b/OvmfPkg/=
Library/PlatformBootManagerLibGrub/QemuKernel.c
similarity index 100%
copy from OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
copy to OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c
--=20
2.25.1

6241 - 6260 of 84265