diff mbox series

[01/13] ti:keys Add EFI signature list

Message ID 20240408213349.96610-2-j-humphreys@ti.com
State Rejected, archived
Delegated to: Heinrich Schuchardt
Headers show
Series EFI: capsule: ti: enable authenticated capsules | expand

Commit Message

Jonathan Humphreys April 8, 2024, 9:33 p.m. UTC
EFI signature list using TI dummy keys.

Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
---
 arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-k3/keys/custMpk.esl

GIT binary patch
literal 1523
zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
D66<<J

literal 0
HcmV?d00001

Comments

Heinrich Schuchardt April 9, 2024, 3:34 a.m. UTC | #1
On 4/8/24 23:33, Jonathan Humphreys wrote:
> EFI signature list using TI dummy keys.

Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.

Best regards

Heinrich

>
> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
> ---
>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>   1 file changed, 0 insertions(+), 0 deletions(-)
>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>
> diff --git a/arch/arm/mach-k3/keys/custMpk.esl b/arch/arm/mach-k3/keys/custMpk.esl
> new file mode 100644
> index 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
> GIT binary patch
> literal 1523
> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
> D66<<J
>
> literal 0
> HcmV?d00001
>
Andrew Davis April 9, 2024, 12:14 p.m. UTC | #2
On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
> On 4/8/24 23:33, Jonathan Humphreys wrote:
>> EFI signature list using TI dummy keys.
> 
> Adding vendor public keys into the code base to lock down generated
> binaries to the vendors unpublished private key does not match well with
> the intent of the GNU public license.
> 

The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).

Andrew

> Best regards
> 
> Heinrich
> 
>>
>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>> ---
>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>>   1 file changed, 0 insertions(+), 0 deletions(-)
>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>>
>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl b/arch/arm/mach-k3/keys/custMpk.esl
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>> GIT binary patch
>> literal 1523
>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>> D66<<J
>>
>> literal 0
>> HcmV?d00001
>>
>
Heinrich Schuchardt April 9, 2024, 7:26 p.m. UTC | #3
On 4/9/24 14:14, Andrew Davis wrote:
> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
>> On 4/8/24 23:33, Jonathan Humphreys wrote:
>>> EFI signature list using TI dummy keys.
>>
>> Adding vendor public keys into the code base to lock down generated
>> binaries to the vendors unpublished private key does not match well with
>> the intent of the GNU public license.
>>
>
> The matching private keys are already published in this same
> repo/directory (arch/arm/mach-k3/keys).
>
> Andrew

Why should we create signed capsules which are already compromised by
publishing the private key?

Best regards

Heinrich

>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>>> ---
>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>>>   1 file changed, 0 insertions(+), 0 deletions(-)
>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>>>
>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
>>> b/arch/arm/mach-k3/keys/custMpk.esl
>>> new file mode 100644
>>> index
>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>>> GIT binary patch
>>> literal 1523
>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>>> D66<<J
>>>
>>> literal 0
>>> HcmV?d00001
>>>
>>
Andrew Davis April 9, 2024, 9:14 p.m. UTC | #4
On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
> On 4/9/24 14:14, Andrew Davis wrote:
>> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
>>> On 4/8/24 23:33, Jonathan Humphreys wrote:
>>>> EFI signature list using TI dummy keys.
>>>
>>> Adding vendor public keys into the code base to lock down generated
>>> binaries to the vendors unpublished private key does not match well with
>>> the intent of the GNU public license.
>>>
>>
>> The matching private keys are already published in this same
>> repo/directory (arch/arm/mach-k3/keys).
>>
>> Andrew
> 
> Why should we create signed capsules which are already compromised by
> publishing the private key?
> 

If you buy these devices you have two options, you can burn real
keys, or you can burn these dummy keys. If you burn dummy keys
then these images will boot and so will any image you or anyone
else wants to boot on the device. (since the keys are published
anyone can make images for them, that is how we do GP (general
purpose) devices these days)

If you burn your own keys, then you switch out these keys here
and your device will only boot images that you permit by signing
with your keys.

You'll find plenty of open source projects do the same and
give out example keys to show how to use real keys, even
official GNU projects.

https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys

Andrew

> Best regards
> 
> Heinrich
> 
>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>>>> ---
>>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>>>>   1 file changed, 0 insertions(+), 0 deletions(-)
>>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>>>>
>>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
>>>> b/arch/arm/mach-k3/keys/custMpk.esl
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>>>> GIT binary patch
>>>> literal 1523
>>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>>>> D66<<J
>>>>
>>>> literal 0
>>>> HcmV?d00001
>>>>
>>>
>
Ilias Apalodimas April 10, 2024, 9:38 a.m. UTC | #5
On Tue, 9 Apr 2024 at 23:14, Andrew Davis <afd@ti.com> wrote:
>
> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
> > On 4/9/24 14:14, Andrew Davis wrote:
> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
> >>> On 4/8/24 23:33, Jonathan Humphreys wrote:
> >>>> EFI signature list using TI dummy keys.
> >>>
> >>> Adding vendor public keys into the code base to lock down generated
> >>> binaries to the vendors unpublished private key does not match well with
> >>> the intent of the GNU public license.
> >>>
> >>
> >> The matching private keys are already published in this same
> >> repo/directory (arch/arm/mach-k3/keys).
> >>
> >> Andrew
> >
> > Why should we create signed capsules which are already compromised by
> > publishing the private key?
> >
>
> If you buy these devices you have two options, you can burn real
> keys, or you can burn these dummy keys. If you burn dummy keys
> then these images will boot and so will any image you or anyone
> else wants to boot on the device. (since the keys are published
> anyone can make images for them, that is how we do GP (general
> purpose) devices these days)
>
> If you burn your own keys, then you switch out these keys here
> and your device will only boot images that you permit by signing
> with your keys.

I am not sure I am following you here.  We don't burn anything in the
case of EFI keys. They are placed in an elf section and we assume the
device will have a chain of trust enabled, naturally verifying those
keys along with the u-boot binary.

>
> You'll find plenty of open source projects do the same and
> give out example keys to show how to use real keys, even
> official GNU projects.

Yes, but the keys defined here are useless unless you have a default
defconfig that uses them and embeds them in the binary. I am not cc'ed
in all the patches of the series, is that added somewhere? And if you
unconditionally enable secure boot It would be far more interesting to
embed the MS SHIM key along with that special key you are trying to
define, so that firmware can boot COTS distros as well

Thanks
/Ilias


>
> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
>
> Andrew
>
> > Best regards
> >
> > Heinrich
> >
> >>
> >>> Best regards
> >>>
> >>> Heinrich
> >>>
> >>>>
> >>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
> >>>> ---
> >>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
> >>>>   1 file changed, 0 insertions(+), 0 deletions(-)
> >>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
> >>>>
> >>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
> >>>> b/arch/arm/mach-k3/keys/custMpk.esl
> >>>> new file mode 100644
> >>>> index
> >>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
> >>>> GIT binary patch
> >>>> literal 1523
> >>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
> >>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
> >>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
> >>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
> >>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
> >>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
> >>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
> >>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
> >>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
> >>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
> >>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
> >>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
> >>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
> >>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
> >>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
> >>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
> >>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
> >>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
> >>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
> >>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
> >>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
> >>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
> >>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
> >>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
> >>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
> >>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
> >>>> D66<<J
> >>>>
> >>>> literal 0
> >>>> HcmV?d00001
> >>>>
> >>>
> >
Andrew Davis April 10, 2024, 3:20 p.m. UTC | #6
On 4/10/24 4:38 AM, Ilias Apalodimas wrote:
> On Tue, 9 Apr 2024 at 23:14, Andrew Davis <afd@ti.com> wrote:
>>
>> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
>>> On 4/9/24 14:14, Andrew Davis wrote:
>>>> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
>>>>> On 4/8/24 23:33, Jonathan Humphreys wrote:
>>>>>> EFI signature list using TI dummy keys.
>>>>>
>>>>> Adding vendor public keys into the code base to lock down generated
>>>>> binaries to the vendors unpublished private key does not match well with
>>>>> the intent of the GNU public license.
>>>>>
>>>>
>>>> The matching private keys are already published in this same
>>>> repo/directory (arch/arm/mach-k3/keys).
>>>>
>>>> Andrew
>>>
>>> Why should we create signed capsules which are already compromised by
>>> publishing the private key?
>>>
>>
>> If you buy these devices you have two options, you can burn real
>> keys, or you can burn these dummy keys. If you burn dummy keys
>> then these images will boot and so will any image you or anyone
>> else wants to boot on the device. (since the keys are published
>> anyone can make images for them, that is how we do GP (general
>> purpose) devices these days)
>>
>> If you burn your own keys, then you switch out these keys here
>> and your device will only boot images that you permit by signing
>> with your keys.
> 
> I am not sure I am following you here.  We don't burn anything in the
> case of EFI keys. They are placed in an elf section and we assume the
> device will have a chain of trust enabled, naturally verifying those
> keys along with the u-boot binary.
> 

Right, you can (and probably should) use different keys stored in the
boot stages to verify the next stages. I was more giving the background
to why we publish our "private" keys at all here. Using the same keys
for every stage (including burning it in as the HW root of trust key)
is to make the examples here easier, but I think I see what you
are saying. It could be better to generate a key-pair as part of
this build for the EFI keys.

>>
>> You'll find plenty of open source projects do the same and
>> give out example keys to show how to use real keys, even
>> official GNU projects.
> 
> Yes, but the keys defined here are useless unless you have a default
> defconfig that uses them and embeds them in the binary. I am not cc'ed
> in all the patches of the series, is that added somewhere? And if you
> unconditionally enable secure boot It would be far more interesting to
> embed the MS SHIM key along with that special key you are trying to
> define, so that firmware can boot COTS distros as well
> 

Using MS SHIM keys here does sound interesting, I'll let Jon comment
on if we want to add that to this series or save for later.

Thanks,
Andrew

> Thanks
> /Ilias
> 
> 
>>
>> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
>>
>> Andrew
>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>>> Best regards
>>>>>
>>>>> Heinrich
>>>>>
>>>>>>
>>>>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>>>>>> ---
>>>>>>    arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>>>>>>    1 file changed, 0 insertions(+), 0 deletions(-)
>>>>>>    create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>>>>>>
>>>>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
>>>>>> b/arch/arm/mach-k3/keys/custMpk.esl
>>>>>> new file mode 100644
>>>>>> index
>>>>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>>>>>> GIT binary patch
>>>>>> literal 1523
>>>>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>>>>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>>>>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>>>>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>>>>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>>>>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>>>>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>>>>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>>>>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>>>>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>>>>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>>>>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>>>>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>>>>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>>>>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>>>>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>>>>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>>>>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>>>>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>>>>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>>>>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>>>>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>>>>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>>>>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>>>>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>>>>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>>>>>> D66<<J
>>>>>>
>>>>>> literal 0
>>>>>> HcmV?d00001
>>>>>>
>>>>>
>>>
Jonathan Humphreys April 10, 2024, 6:34 p.m. UTC | #7
Ilias Apalodimas <ilias.apalodimas@linaro.org> writes:

> On Tue, 9 Apr 2024 at 23:14, Andrew Davis <afd@ti.com> wrote:
>>
>> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
>> > On 4/9/24 14:14, Andrew Davis wrote:
>> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
>> >>> On 4/8/24 23:33, Jonathan Humphreys wrote:
>> >>>> EFI signature list using TI dummy keys.
>> >>>
>> >>> Adding vendor public keys into the code base to lock down generated
>> >>> binaries to the vendors unpublished private key does not match well with
>> >>> the intent of the GNU public license.
>> >>>
>> >>
>> >> The matching private keys are already published in this same
>> >> repo/directory (arch/arm/mach-k3/keys).
>> >>
>> >> Andrew
>> >
>> > Why should we create signed capsules which are already compromised by
>> > publishing the private key?
>> >
>>
>> If you buy these devices you have two options, you can burn real
>> keys, or you can burn these dummy keys. If you burn dummy keys
>> then these images will boot and so will any image you or anyone
>> else wants to boot on the device. (since the keys are published
>> anyone can make images for them, that is how we do GP (general
>> purpose) devices these days)
>>
>> If you burn your own keys, then you switch out these keys here
>> and your device will only boot images that you permit by signing
>> with your keys.
>
> I am not sure I am following you here.  We don't burn anything in the
> case of EFI keys. They are placed in an elf section and we assume the
> device will have a chain of trust enabled, naturally verifying those
> keys along with the u-boot binary.
>
>>
>> You'll find plenty of open source projects do the same and
>> give out example keys to show how to use real keys, even
>> official GNU projects.
>
> Yes, but the keys defined here are useless unless you have a default
> defconfig that uses them and embeds them in the binary. I am not cc'ed
> in all the patches of the series, is that added somewhere? And if you

Yes, they are part of this series
https://lore.kernel.org/r/20240408213349.96610-1-j-humphreys@ti.com.
Thanks for the reviews.

> unconditionally enable secure boot It would be far more interesting to
> embed the MS SHIM key along with that special key you are trying to
> define, so that firmware can boot COTS distros as well

Yes, we should consider.  But since that is outside of the EFI capsule
use case, I would rather take it up in a separate patch.

>
> Thanks
> /Ilias
>
>
>>
>> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
>>
>> Andrew
>>
>> > Best regards
>> >
>> > Heinrich
>> >
>> >>
>> >>> Best regards
>> >>>
>> >>> Heinrich
>> >>>
>> >>>>
>> >>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>> >>>> ---
>> >>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>> >>>>   1 file changed, 0 insertions(+), 0 deletions(-)
>> >>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>> >>>>
>> >>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
>> >>>> b/arch/arm/mach-k3/keys/custMpk.esl
>> >>>> new file mode 100644
>> >>>> index
>> >>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>> >>>> GIT binary patch
>> >>>> literal 1523
>> >>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>> >>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>> >>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>> >>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>> >>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>> >>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>> >>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>> >>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>> >>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>> >>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>> >>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>> >>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>> >>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>> >>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>> >>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>> >>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>> >>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>> >>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>> >>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>> >>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>> >>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>> >>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>> >>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>> >>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>> >>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>> >>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>> >>>> D66<<J
>> >>>>
>> >>>> literal 0
>> >>>> HcmV?d00001
>> >>>>
>> >>>
>> >
Ilias Apalodimas April 12, 2024, 9:55 a.m. UTC | #8
Hi Jon,


On Wed, 10 Apr 2024 at 20:35, Jon Humphreys <j-humphreys@ti.com> wrote:
>
> Ilias Apalodimas <ilias.apalodimas@linaro.org> writes:
>
> > On Tue, 9 Apr 2024 at 23:14, Andrew Davis <afd@ti.com> wrote:
> >>
> >> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
> >> > On 4/9/24 14:14, Andrew Davis wrote:
> >> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
> >> >>> On 4/8/24 23:33, Jonathan Humphreys wrote:
> >> >>>> EFI signature list using TI dummy keys.
> >> >>>
> >> >>> Adding vendor public keys into the code base to lock down generated
> >> >>> binaries to the vendors unpublished private key does not match well with
> >> >>> the intent of the GNU public license.
> >> >>>
> >> >>
> >> >> The matching private keys are already published in this same
> >> >> repo/directory (arch/arm/mach-k3/keys).
> >> >>
> >> >> Andrew
> >> >
> >> > Why should we create signed capsules which are already compromised by
> >> > publishing the private key?
> >> >
> >>
> >> If you buy these devices you have two options, you can burn real
> >> keys, or you can burn these dummy keys. If you burn dummy keys
> >> then these images will boot and so will any image you or anyone
> >> else wants to boot on the device. (since the keys are published
> >> anyone can make images for them, that is how we do GP (general
> >> purpose) devices these days)
> >>
> >> If you burn your own keys, then you switch out these keys here
> >> and your device will only boot images that you permit by signing
> >> with your keys.
> >
> > I am not sure I am following you here.  We don't burn anything in the
> > case of EFI keys. They are placed in an elf section and we assume the
> > device will have a chain of trust enabled, naturally verifying those
> > keys along with the u-boot binary.
> >
> >>
> >> You'll find plenty of open source projects do the same and
> >> give out example keys to show how to use real keys, even
> >> official GNU projects.
> >
> > Yes, but the keys defined here are useless unless you have a default
> > defconfig that uses them and embeds them in the binary. I am not cc'ed
> > in all the patches of the series, is that added somewhere? And if you
>
> Yes, they are part of this series
> https://lore.kernel.org/r/20240408213349.96610-1-j-humphreys@ti.com.
> Thanks for the reviews.
>
> > unconditionally enable secure boot It would be far more interesting to
> > embed the MS SHIM key along with that special key you are trying to
> > define, so that firmware can boot COTS distros as well
>
> Yes, we should consider.  But since that is outside of the EFI capsule
> use case, I would rather take it up in a separate patch.

Ok, the commit message wasn't clear, and based on Andrews's initial
response I thought you wanted to use those for UEFI secure boot, not
capsule updates.
Those are your boards so I won't NAK this, but I'd strongly advise
*not* to add this.  I assume you want capsule auth by default because
SystemReady-IR >=2.0 mandates it?

In that case, it would be a far better idea to document the process of
creating signed capsules clearly either in U-Boots EFI docs and/or
your board docs.
I am pretty confident that if we merge this now we will have future
products using the keys above

Thanks
/Ilias
>
> >
> > Thanks
> > /Ilias
> >
> >
> >>
> >> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
> >>
> >> Andrew
> >>
> >> > Best regards
> >> >
> >> > Heinrich
> >> >
> >> >>
> >> >>> Best regards
> >> >>>
> >> >>> Heinrich
> >> >>>
> >> >>>>
> >> >>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
> >> >>>> ---
> >> >>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
> >> >>>>   1 file changed, 0 insertions(+), 0 deletions(-)
> >> >>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
> >> >>>>
> >> >>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
> >> >>>> b/arch/arm/mach-k3/keys/custMpk.esl
> >> >>>> new file mode 100644
> >> >>>> index
> >> >>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
> >> >>>> GIT binary patch
> >> >>>> literal 1523
> >> >>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
> >> >>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
> >> >>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
> >> >>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
> >> >>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
> >> >>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
> >> >>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
> >> >>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
> >> >>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
> >> >>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
> >> >>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
> >> >>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
> >> >>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
> >> >>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
> >> >>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
> >> >>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
> >> >>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
> >> >>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
> >> >>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
> >> >>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
> >> >>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
> >> >>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
> >> >>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
> >> >>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
> >> >>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
> >> >>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
> >> >>>> D66<<J
> >> >>>>
> >> >>>> literal 0
> >> >>>> HcmV?d00001
> >> >>>>
> >> >>>
> >> >
Jonathan Humphreys April 12, 2024, 9:48 p.m. UTC | #9
Ilias Apalodimas <ilias.apalodimas@linaro.org> writes:

> Hi Jon,
>
>
> On Wed, 10 Apr 2024 at 20:35, Jon Humphreys <j-humphreys@ti.com> wrote:
>>
>> Ilias Apalodimas <ilias.apalodimas@linaro.org> writes:
>>
>> > On Tue, 9 Apr 2024 at 23:14, Andrew Davis <afd@ti.com> wrote:
>> >>
>> >> On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
>> >> > On 4/9/24 14:14, Andrew Davis wrote:
>> >> >> On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
>> >> >>> On 4/8/24 23:33, Jonathan Humphreys wrote:
>> >> >>>> EFI signature list using TI dummy keys.
>> >> >>>
>> >> >>> Adding vendor public keys into the code base to lock down generated
>> >> >>> binaries to the vendors unpublished private key does not match well with
>> >> >>> the intent of the GNU public license.
>> >> >>>
>> >> >>
>> >> >> The matching private keys are already published in this same
>> >> >> repo/directory (arch/arm/mach-k3/keys).
>> >> >>
>> >> >> Andrew
>> >> >
>> >> > Why should we create signed capsules which are already compromised by
>> >> > publishing the private key?
>> >> >
>> >>
>> >> If you buy these devices you have two options, you can burn real
>> >> keys, or you can burn these dummy keys. If you burn dummy keys
>> >> then these images will boot and so will any image you or anyone
>> >> else wants to boot on the device. (since the keys are published
>> >> anyone can make images for them, that is how we do GP (general
>> >> purpose) devices these days)
>> >>
>> >> If you burn your own keys, then you switch out these keys here
>> >> and your device will only boot images that you permit by signing
>> >> with your keys.
>> >
>> > I am not sure I am following you here.  We don't burn anything in the
>> > case of EFI keys. They are placed in an elf section and we assume the
>> > device will have a chain of trust enabled, naturally verifying those
>> > keys along with the u-boot binary.
>> >
>> >>
>> >> You'll find plenty of open source projects do the same and
>> >> give out example keys to show how to use real keys, even
>> >> official GNU projects.
>> >
>> > Yes, but the keys defined here are useless unless you have a default
>> > defconfig that uses them and embeds them in the binary. I am not cc'ed
>> > in all the patches of the series, is that added somewhere? And if you
>>
>> Yes, they are part of this series
>> https://lore.kernel.org/r/20240408213349.96610-1-j-humphreys@ti.com.
>> Thanks for the reviews.
>>
>> > unconditionally enable secure boot It would be far more interesting to
>> > embed the MS SHIM key along with that special key you are trying to
>> > define, so that firmware can boot COTS distros as well
>>
>> Yes, we should consider.  But since that is outside of the EFI capsule
>> use case, I would rather take it up in a separate patch.
>
> Ok, the commit message wasn't clear, and based on Andrews's initial
> response I thought you wanted to use those for UEFI secure boot, not
> capsule updates.
> Those are your boards so I won't NAK this, but I'd strongly advise
> *not* to add this.  I assume you want capsule auth by default because
> SystemReady-IR >=2.0 mandates it?
>
> In that case, it would be a far better idea to document the process of
> creating signed capsules clearly either in U-Boots EFI docs and/or
> your board docs.
> I am pretty confident that if we merge this now we will have future
> products using the keys above

Thanks Ilias.

If I understand you correctly, I don't agree with the approach of not
having a working implementation so that developers are forced to think
through their support.  Not having a feature enabled in upstream leads
to latent bugs, bit rot, lack of coordination and openess, etc.  It
worries me that there are so many claims of authenticated capsule
support but nothing in upstream on those devices.

But I absolutely acknowledge your concern that if we make this 'just
work' then developers will overlook the details and not properly secure
their solutions.

What I suggest to mitigate this:
1) as you say, add documentation, including a 'porting guide' section so
   developers know what steps they need to take, and
2) Add a developer config that is set by default.  With this config set,
   during capsule updates, emit a warning message that
   instructs them to read the porting section of the doc to ensure they
   have secured their solution.  To remove the warning, a developer would
   follow the porting guidelines and then unset the "developer config"
   configuration to signify they have secured the solution.  This is
   what optee does, emitting the below during boot, until the config is
   unset:

I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check
https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html

Last, I am pondering the idea of not including the actual .esl
certificate, but rather adding a make step that would generate the
certificate from a given keypair.  For the TI upstream implementation,
we would point to the open developer keys already being used to
demonstrate secure boot.  As part of porting, the developer would point
to their own keys. That way the certificate has the developer's info,
even if they are using our open keys for development purposes.
Thoughts?

Outside of the capsule authentication aspect, the porting section would
be a good place to remind the developer to define his own capsule GUIDs
as well.

Jon

>
> Thanks
> /Ilias
>>
>> >
>> > Thanks
>> > /Ilias
>> >
>> >
>> >>
>> >> https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
>> >>
>> >> Andrew
>> >>
>> >> > Best regards
>> >> >
>> >> > Heinrich
>> >> >
>> >> >>
>> >> >>> Best regards
>> >> >>>
>> >> >>> Heinrich
>> >> >>>
>> >> >>>>
>> >> >>>> Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
>> >> >>>> ---
>> >> >>>>   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
>> >> >>>>   1 file changed, 0 insertions(+), 0 deletions(-)
>> >> >>>>   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
>> >> >>>>
>> >> >>>> diff --git a/arch/arm/mach-k3/keys/custMpk.esl
>> >> >>>> b/arch/arm/mach-k3/keys/custMpk.esl
>> >> >>>> new file mode 100644
>> >> >>>> index
>> >> >>>> 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52
>> >> >>>> GIT binary patch
>> >> >>>> literal 1523
>> >> >>>> zcmZ1&d0^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
>> >> >>>> z&78AJODc2mtxpELY@Awc9&O)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
>> >> >>>> zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
>> >> >>>> zQpnB26;PC)oLXF*UsMbeWai-t@l*&dEdVMmF_blshP#N9QH-w`BJNO<sh6CeYal1i
>> >> >>>> zYh-L-W?*PwYGi0=7A4MWYz$;tLb-$9{Y^|t$U)A?%D~*j#Lr;R#Kgta#Kg$3Uu2!<
>> >> >>>> zjryX?*~({Md+?>+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
>> >> >>>> z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)&i+#e3fJowDZO)JR83lIcbw(hMu}}Y
>> >> >>>> z2ZZwYAI-LVx@^G;HdkgxaX&Hnl_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
>> >> >>>> z{LIBUzm&K9j_CMw_SIFfPdcT#zmg6g<ji}(R`6geJLk-#o7bK^&&fT}#2zsD`=c9g
>> >> >>>> zFUCK<Fz@{2kel&$W6zl<d|WNk#ZsNRd{_N_SJxWvh0*K$j!m)c@oT>{#b(Lp`M3Uj
>> >> >>>> zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
>> >> >>>> ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
>> >> >>>> z8dh8T-~Dmrp2?yk3O6Gqbz7O@<TEz<^zIa7d#PKtHKHeAg?V0DMSin^o3F|IEfQWk
>> >> >>>> zcmJwBy6&2hKub%G{j3IK(?7m@uI43#1e~wSZJ5sTtDjrp@7@{O3(faN{`Gp}x{$M5
>> >> >>>> z{A7`c@pjfYq1Z=JvgZ^-zCC<(HFTBwYhTX$k`7IJX`SM!H}f`Mv+(Op6uVY(<(^o4
>> >> >>>> zpyXAj9nF_c-1A<UIel9%6Eh<NBXSA>W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
>> >> >>>> z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<<LS+lxk$@$kYlG_hXu6p%jvB<%l
>> >> >>>> zmcsdI9w!^rFPt^&c~{1?L~DJ4TRPv>t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
>> >> >>>> zKlQ}fzw*izXI|}|r!O*nb&cP9#VhHRn;B<SRflN2Jl(*;W4e0LD$ORRIdjjhURZH+
>> >> >>>> zXWR0Vllb2@>`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~<l(HQxHJxzF!T_>+5t
>> >> >>>> z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
>> >> >>>> z_N{pmM}uCi3UWO3=hMc<s}m1Jx4GS4F(<_N`R|o+)eAK3Yx{o$ygRe!;<_EoF&UhP
>> >> >>>> zrslJ=2XA9^$j#UDYwo;ZvZwb!|L%YP%v|ie|7-1PP+q3DZ&vEWgHHrjHv|NzEVjO?
>> >> >>>> zKFeRbXv>iTPl?N16Xv@buq_d@TU<MB;uD_jX^$J`&*C>`uX0_s&g9M2C6cKx4E;{?
>> >> >>>> zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
>> >> >>>> z>fTMIw2!Me3{Dw*WZotC<4@h<H`zaL+~Es<{Ccj5yS7zyNU!YsTG`^JqA6NkU%vnV
>> >> >>>> D66<<J
>> >> >>>>
>> >> >>>> literal 0
>> >> >>>> HcmV?d00001
>> >> >>>>
>> >> >>>
>> >> >
diff mbox series

Patch

diff --git a/arch/arm/mach-k3/keys/custMpk.esl b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index 0000000000000000000000000000000000000000..2feb704e0a5fd126410de451d3c0fa4d3edccc52