Bug 1198458 - (CVE-2022-28737) VUL-0: CVE-2022-28737: shim: buffer overflow
(CVE-2022-28737)
VUL-0: CVE-2022-28737: shim: buffer overflow
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Tseng
Security Team bot
https://smash.suse.de/issue/328974/
CVSSv3.1:SUSE:CVE-2022-28737:8.4:(AV:...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-04-13 13:21 UTC by Marcus Meissner
Modified: 2022-08-09 16:35 UTC (History)
10 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jlee: needinfo? (jsegitz)


Attachments
shim: update-sbat-v1.tar.gz (5.04 KB, application/octet-stream)
2022-04-26 02:56 UTC, Michael Chang
Details
mokutil: set-sbat-v1.tar.gz (3.82 KB, application/octet-stream)
2022-04-26 03:00 UTC, Michael Chang
Details
shim: Patches for CVE-2022-28737 (2.16 KB, application/octet-stream)
2022-05-04 02:36 UTC, Michael Chang
Details
fix-CVE-2022-28737.tar.gz (7.80 KB, application/octet-stream)
2022-05-11 07:16 UTC, Michael Chang
Details
grub2.cve_2021_3695.disclosure.txt (2.81 KB, text/plain)
2022-05-11 07:57 UTC, Michael Chang
Details
fix-CVE-2022-28737-v4.tar.gz (3.20 KB, application/octet-stream)
2022-05-25 04:16 UTC, Michael Chang
Details
disclosure.txt (4.55 KB, text/plain)
2022-06-01 04:00 UTC, Michael Chang
Details
shim-15.6~rc2.tar.bz2 (1.28 MB, application/octet-stream)
2022-06-01 04:06 UTC, Michael Chang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2022-04-13 13:21:57 UTC
CRD: 2022-04-26

from grub2 predisclosure group

currently trying to find the details.
Comment 1 Michael Chang 2022-04-13 13:58:16 UTC
AFAIK the CRD may have been moved to May 17 ?
Comment 2 Marcus Meissner 2022-04-13 14:11:20 UTC
i am looking at keybase, grub2.cve_2021_3695 #announcements and I do not see a change there.


I caught up most of it ... so most generic question is:

- Do we need to do another UEFI signing key change this time?

As I read between the lines that SBAT seems not be fully usable yet, and also with a shim bug this might be necessary even without SBAT?
Comment 3 Tseng 2022-04-14 03:01:49 UTC
Hi Gentlemen,

1) shim-15.5 is still under debugging and testing. I suggest using shim-15.4 as a  stable version on Apr 26 (CRD: 2022-04-26).

2) Increase the generation number of SBAT is useless when system manager wants to do that. It needs more time to test and fix if it is really a bug.

BR
Dennis
Comment 4 Michael Chang 2022-04-14 04:02:49 UTC
(In reply to Marcus Meissner from comment #2)
> i am looking at keybase, grub2.cve_2021_3695 #announcements and I do not see
> a change there.
> 
> 
> I caught up most of it ... so most generic question is:
> 
> - Do we need to do another UEFI signing key change this time?
> 
> As I read between the lines that SBAT seems not be fully usable yet, and
> also with a shim bug this might be necessary even without SBAT?

It would not only be weighted by the shim bug, but also with security features like new shim lock protocol will be able to verify sbat if it is available, together with other important hardening like NX support and certmule (I think it was formerly known as "one-shim" in the sbat doc). 

I'd expect them also request a key rotation this time to prevent old shim for being booted to bypass the shim lock sbat valiaction or trying to circumvent NX via old binaries.

So this time would also have lots churns like last time. Key rotation together with sbat level bump. For sbat the work is still on-going to deliver sbat level update via mokutil or bringing a brand tool "sbatutil" to the table.
Comment 5 Michael Chang 2022-04-14 04:09:33 UTC
(In reply to Tseng from comment #3)
> Hi Gentlemen,
> 
> 1) shim-15.5 is still under debugging and testing. I suggest using shim-15.4
> as a  stable version on Apr 26 (CRD: 2022-04-26).

I'm not sure if we could stick to 15.4 this time. If new key rotation is requested we have to bump it to 15.5.
 
> 2) Increase the generation number of SBAT is useless when system manager
> wants to do that. It needs more time to test and fix if it is really a bug.

The sbat didn't work so far, but still you can test by enabling ENABLE_SHIM_DEVEL build option and then use SbatLevel_DEVEL uefi RT variable to experiment sbat revocation. 

The upstream is working on the tooling side to deliver sbat update. The CRD is postpone for that matters.

Thanks.
Comment 6 Marcus Meissner 2022-04-19 07:43:26 UTC
There will be requirements posted for the shim review round, and I also expect 15.5 to be the baselevel requirement.

(Have not seen the requirements yet.)
Comment 12 Marcus Meissner 2022-04-20 11:14:50 UTC
CRD: 2022-05-24
Comment 14 Michael Chang 2022-04-26 02:56:31 UTC
Created attachment 858422 [details]
shim: update-sbat-v1.tar.gz

The first round of sbat revocation management from keybase - shim's part.

The revocation data (for previous and current) is living in sbat.h so it can be covered by signing. Adding support to perform actions like current, previous and empty so it can be managed by mokutil.
Comment 15 Michael Chang 2022-04-26 03:00:29 UTC
Created attachment 858423 [details]
mokutil: set-sbat-v1.tar.gz

The first round of sbat revocation management from keybase - mokutil's part.

Control how shim will apply SBAT revocations:

 mokutil --set-sbat latest      applies the latest SBAT revocations
                                (default behavior)
 mokutil --set-sbat previous    applies previous SBAT revocations to
                                allow falling back to an older release

 In both of the above cases shim will only apply SBAT revocations that
are newer than the ones currently installed.

 mokutil --set-sbat delete      resets SBAT revocations only if Secure
                                Boot is disabled. This setting does not
                                persist.
Comment 16 Michael Chang 2022-04-26 03:12:10 UTC
Hi Joey and Dennis,

The two tarballs attached above are outstanding patches for SBAT management from keybase git. They are based on shim 15.5 and mokutil 0.5.0 respectively.

I think we we should start to test them and collecting issues. Please remember not to discuss or disclose any of the works outside.

Thanks.
Comment 17 Joey Lee 2022-04-26 05:24:14 UTC
(In reply to Michael Chang from comment #16)
> Hi Joey and Dennis,
> 
> The two tarballs attached above are outstanding patches for SBAT management
> from keybase git. They are based on shim 15.5 and mokutil 0.5.0 respectively.
> 
> I think we we should start to test them and collecting issues. Please
> remember not to discuss or disclose any of the works outside.
> 
> Thanks.

I have send submitreq to 15-SP4 for update to mokutil 0.5.0. I hope it not too late: 
https://build.suse.de/request/show/270776

I will also backport to old mokutil.
Comment 18 Joey Lee 2022-04-26 07:37:57 UTC
(In reply to Michael Chang from comment #14)
> Created attachment 858422 [details]
> shim: update-sbat-v1.tar.gz
> 
> The first round of sbat revocation management from keybase - shim's part.
> 
> The revocation data (for previous and current) is living in sbat.h so it can
> be covered by signing. Adding support to perform actions like current,
> previous and empty so it can be managed by mokutil.

Patches in update-sbat-v1.tar.gz are backported to 15.5 in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/shim

@Dennis please help to test
Comment 19 Marcus Meissner 2022-04-27 08:19:02 UTC
in which group did you get the sbats ? not sure if i am subscribed there?
Comment 22 Joey Lee 2022-04-28 08:51:25 UTC
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz
> 
> The first round of sbat revocation management from keybase - mokutil's part.
> 

I have backported those patches in tarball to mok 0.4.0 on 15-SP4 in my home branch:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/mokutil

I also backported --list-sbat function and some related patches.

The 15-SP4 mokutil will be updated to 0.5.0 in GMC image. We will also backport set-sbat patches to 0.5.0, and more older mokutil.

> Control how shim will apply SBAT revocations:
> 
>  mokutil --set-sbat latest      applies the latest SBAT revocations
>                                 (default behavior)
>  mokutil --set-sbat previous    applies previous SBAT revocations to
>                                 allow falling back to an older release
> 
>  In both of the above cases shim will only apply SBAT revocations that
> are newer than the ones currently installed.
> 
>  mokutil --set-sbat delete      resets SBAT revocations only if Secure
>                                 Boot is disabled. This setting does not
>                                 persist.
Comment 23 Joey Lee 2022-05-01 09:14:41 UTC
The version of mokutil are:
11-SP3, 11-SP4                                          mokutil-0.1.0
12, 12-SP1, 12-SP2, 12-SP3, 12-SP4, 12-SP5              mokutil-0.2.0
15, 15-SP1,                                             mokutil-0.3.0
15-SP2, 15-SP3, 15-SP4                                  mokutil-0.4.0
Comment 24 Joey Lee 2022-05-01 09:16:31 UTC
(In reply to Joey Lee from comment #22)
> (In reply to Michael Chang from comment #15)
> > Created attachment 858423 [details]
> > mokutil: set-sbat-v1.tar.gz
> >
> > The first round of sbat revocation management from keybase - mokutil's part.
> >
>
> I have backported those patches in tarball to mok 0.4.0 on 15-SP4 in my home
> branch:
>
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/mokutil
>
> I also backported --list-sbat function and some related patches.
>
> The 15-SP4 mokutil will be updated to 0.5.0 in GMC image. We will also
> backport set-sbat patches to 0.5.0, and more older mokutil.
>

Backported to mokutil 0.1.0 for 11-SP3, 11-SP4:

https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-11-SP3:Shim-Update
Comment 25 Joey Lee 2022-05-01 09:18:31 UTC
(In reply to Joey Lee from comment #23)
> The version of mokutil are:
> 11-SP3, 11-SP4                                          mokutil-0.1.0
> 12, 12-SP1, 12-SP2, 12-SP3, 12-SP4, 12-SP5              mokutil-0.2.0
> 15, 15-SP1,                                             mokutil-0.3.0
> 15-SP2, 15-SP3, 15-SP4                                  mokutil-0.4.0

15-SP4 be updated to mokutil-0.5.0. So

11-SP3, 11-SP4                                          mokutil-0.1.0
12, 12-SP1, 12-SP2, 12-SP3, 12-SP4, 12-SP5              mokutil-0.2.0
15, 15-SP1,                                             mokutil-0.3.0
15-SP2, 15-SP3                                          mokutil-0.4.0
15-SP4                                                  mokutil-0.5.0
Comment 26 Tseng 2022-05-01 16:37:40 UTC
(In reply to Joey Lee from comment #18)
> (In reply to Michael Chang from comment #14)
> > Created attachment 858422 [details]
> > shim: update-sbat-v1.tar.gz
> > 
> > The first round of sbat revocation management from keybase - shim's part.
> > 
> > The revocation data (for previous and current) is living in sbat.h so it can
> > be covered by signing. Adding support to perform actions like current,
> > previous and empty so it can be managed by mokutil.
> 
> Patches in update-sbat-v1.tar.gz are backported to 15.5 in my home branch on
> IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/shim
> 
> @Dennis please help to test

SBAT revocation testing status :
1) The sbat revocation in 15.5 has been tested, and it works well in the emulation condition.
2) Without the mokutil as a configuration interface, I used a get_variable_attr() emulator to emulate PREVIOUS, LATEST and RESET test cases.
3) New version of mokutil will be backported to 15.5 soon.
4) Some comments about the source codes(set_sbat_uefi_variable) are also submitted to main stream.
5) mokutil is used to control 2 hard code variables defined in 15.5 sbat.h, instead of 1 hard code variable in 15.4 sbat.h. Obviously, the bug in 15.4 has been fixed.
6) More testing will keep going.
Comment 27 Joey Lee 2022-05-02 07:05:39 UTC
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz

Backported to mokutil 0.2.0 for 12, 12-SP1, 12-SP2, 12-SP3, 12-SP4, 12-SP5:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-12:Update/mokutil
Comment 28 Tseng 2022-05-03 01:35:12 UTC
(In reply to Tseng from comment #26)
> (In reply to Joey Lee from comment #18)
> > (In reply to Michael Chang from comment #14)
> > > Created attachment 858422 [details]
> > > shim: update-sbat-v1.tar.gz
> > > 
> > > The first round of sbat revocation management from keybase - shim's part.
> > > 
> > > The revocation data (for previous and current) is living in sbat.h so it can
> > > be covered by signing. Adding support to perform actions like current,
> > > previous and empty so it can be managed by mokutil.
> > 
> > Patches in update-sbat-v1.tar.gz are backported to 15.5 in my home branch on
> > IBS:
> > 
> > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update/shim
> > 
> > @Dennis please help to test
> 
> SBAT revocation testing status :
> 1) The sbat revocation in 15.5 has been tested, and it works well in the
> emulation condition.
> 2) Without the mokutil as a configuration interface, I used a
> get_variable_attr() emulator to emulate PREVIOUS, LATEST and RESET test
> cases.
> 3) Some comments about the source codes(set_sbat_uefi_variable) are also
> submitted to main stream.
> 4) mokutil is used to control 2 hard code variables defined in 15.5 sbat.h,
> instead of 1 hard code variable in 15.4 sbat.h. Obviously, the bug in 15.4
> has been fixed.
> 5) More testing will keep going.

Main stream has accepted my suggestion about the redundant codes --get_variable_attr() in set_sbat_uefi_variable() : "Thank you and @dennis-tseng99 for pointing this out, that is indeed redundant. Fixed." reference: https://github.com/rhboot/shim/pull/467
Comment 29 Joey Lee 2022-05-03 07:26:29 UTC
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz

Backported to mokutil 0.3.0 for 15, 15-SP1:

https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-15:Update
Comment 30 Michael Chang 2022-05-04 02:36:30 UTC
Created attachment 858625 [details]
shim: Patches for CVE-2022-28737

Note: The patch is based on rhboot/shim master branch.
Comment 31 Joey Lee 2022-05-04 05:54:42 UTC
(In reply to Tseng from comment #28)
> (In reply to Tseng from comment #26)
[...snip]
> 
> Main stream has accepted my suggestion about the redundant codes
> --get_variable_attr() in set_sbat_uefi_variable() : "Thank you and
> @dennis-tseng99 for pointing this out, that is indeed redundant. Fixed."
> reference: https://github.com/rhboot/shim/pull/467

I have respin the shim-bsc1198458-SBAT-revocation-update-support.patch by the version in jsetje/shim git.

Thanks!

(In reply to Michael Chang from comment #30)
> Created attachment 858625 [details]
> shim: Patches for CVE-2022-28737
> 
> Note: The patch is based on rhboot/shim master branch.

I have port CVE patches to my shim branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/shim

@Dennis 
Please help to test it again. Thanks!
Comment 32 Joey Lee 2022-05-05 08:10:13 UTC
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz
> 

Backported to 0.4.0 for 15-SP2, 15-SP3:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP3:Shim-Update/mokutil
Comment 33 Joey Lee 2022-05-05 09:32:12 UTC
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz
> 

Backported to mokutil 0.5.0 for 15-SP4:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/mokutil
Comment 34 Tseng 2022-05-06 02:20:13 UTC
(In reply to Joey Lee from comment #31)
> (In reply to Tseng from comment #28)
> > (In reply to Tseng from comment #26)
> [...snip]
> > 
> > Main stream has accepted my suggestion about the redundant codes
> > --get_variable_attr() in set_sbat_uefi_variable() : "Thank you and
> > @dennis-tseng99 for pointing this out, that is indeed redundant. Fixed."
> > reference: https://github.com/rhboot/shim/pull/467
> 
> I have respin the shim-bsc1198458-SBAT-revocation-update-support.patch by
> the version in jsetje/shim git.
> 
> Thanks!
> 
> (In reply to Michael Chang from comment #30)
> > Created attachment 858625 [details]
> > shim: Patches for CVE-2022-28737
> > 
> > Note: The patch is based on rhboot/shim master branch.
> 
> I have port CVE patches to my shim branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/shim
> 
> @Dennis 
> Please help to test it again. Thanks!

[testing status]
1) mokutil-0.5.0 can pass the exact parameter(sbat action) to Joey's respin shim now.
2) Upstream has changed the set-variable name from "SbatAction" to "SbatPolicy" in its new shim version after I gave him some suggestion. This is why it will get failed if using mokutil-0.4.0 to configure sbat parameter(s).
3) more testing will be keep going
4) fail to verify shim.efi by IBS public key getting through :
   >osc signkey --sslcert home:joeyli > my_public.crt
   >openssl x509 -in my_public.crt -outform DER -out shim-ibs-public-key.der
Comment 36 Joey Lee 2022-05-07 01:04:51 UTC
(In reply to Michael Chang from comment #14)
> Created attachment 858422 [details]
> shim: update-sbat-v1.tar.gz
> 
(In reply to Michael Chang from comment #15)
> Created attachment 858423 [details]
> mokutil: set-sbat-v1.tar.gz
> 

I have backported the above patches to shim and mokutil for openSUSE:Factory in my branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:openSUSE:Factory/shim

https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:openSUSE:Factory/mokutil

@Dennis
Could you please help to test?
Comment 37 Tseng 2022-05-07 02:07:51 UTC
(In reply to Joey Lee from comment #36)
> (In reply to Michael Chang from comment #14)
> > Created attachment 858422 [details]
> > shim: update-sbat-v1.tar.gz
> > 
> (In reply to Michael Chang from comment #15)
> > Created attachment 858423 [details]
> > mokutil: set-sbat-v1.tar.gz
> > 
> 
> I have backported the above patches to shim and mokutil for openSUSE:Factory
> in my branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:
> openSUSE:Factory/shim
> 
> https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:
> openSUSE:Factory/mokutil
> 
> @Dennis
> Could you please help to test?


SBAT testing: 
[requirement]
The new shim must be capable of blocking GRUB2.

[result]
The new shim is NOT working.

[root cause] 
If you compare the new shim codes with the previous one, you can find that upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located in include/sbat.h from "shim,2\ngrub,2\n" to "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data comparison, e.g. component name

[solution]
1) change code back to previous one which is "shim,2\ngrub,2\n"
2) set default sbat policy to "latest", rather than "previous"
3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to avoid shim module itself from sbat blocking. (I'm not sure the functionality of data/sbat.vendor.csv is similar to data/sbat.csv)
4) after changing above 3 points, I can successfully block GRUB2 now:

����������������������������������������������
�                                    ERROR                                     �
�                                                                              �
�                Verification failed: (0x1A) Security Violation                �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                     ����Ŀ                                 �
�                                     � OK �                                 �
�                                     ����                                  �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
�                                                                              �
������������������������������������������������
Comment 38 Joey Lee 2022-05-10 08:17:01 UTC
(In reply to Tseng from comment #37)
> (In reply to Joey Lee from comment #36)
[...snip]
> 
> SBAT testing: 
> [requirement]
> The new shim must be capable of blocking GRUB2.
> 
> [result]
> The new shim is NOT working.
> 
> [root cause] 
> If you compare the new shim codes with the previous one, you can find that
> upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located
> in include/sbat.h from "shim,2\ngrub,2\n" to
> "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data
> comparison, e.g. component name
> 
> [solution]
> 1) change code back to previous one which is "shim,2\ngrub,2\n"
> 2) set default sbat policy to "latest", rather than "previous"
> 3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to
> avoid shim module itself from sbat blocking. (I'm not sure the functionality
> of data/sbat.vendor.csv is similar to data/sbat.csv)
> 4) after changing above 3 points, I can successfully block GRUB2 now:
                                                                        
I just add a SUSE specific patch shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch to change SBAT_VARs to:

        SBAT_VAR_PREVIOUS = sbat,1,2021030218\n
        SBAT_VAR_LATEST = sbat,1,2022050100\nshim.sle,2\ngrub.sle,2\n
                        = sbat,1,2022050100
                          shim.sle,2
                          grub.sle,2

I also increased the distro_sbat number in shim.spec to 2. So the .sbat section in new shim.efi will be:

sbat, 1, SBAT Version, sbat, 1, https://github.com/rhboot/shim/blob/main/SBAT.md        
shim, 1, UEFI shim, shim, 1, https://github.com/rhboot/shim
shim.sle, 2, SUSE Linux Enterprise, shim, 15.4, mail:security-team@suse.de 

The first two entries are from data/sbat.csv, the third entry is from shim.spec writes to data/sbat.vendor.csv.

Our .sbat section in old shim.efi is:

sbat, 1, SBAT Version, sbat, 1, https://github.com/rhboot/shim/blob/main/SBAT.md        
shim, 1, UEFI shim, shim, 1, https://github.com/rhboot/shim
shim.sle, 1, SUSE Linux Enterprise, shim, 15.4, mail:security-team@suse.de

And the .sbat section in old grub2 is:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.sle,1,SUSE Linux Enterprise,grub2,2.06,mail:security-team@suse.de

Then new shim can use SBAT_VAR_LATEST to revoke old shim and grub2 with their third policy.
Comment 39 Joey Lee 2022-05-10 08:19:54 UTC
(In reply to Joey Lee from comment #38)
> (In reply to Tseng from comment #37)
> > (In reply to Joey Lee from comment #36)
> [...snip]
> > 
> > SBAT testing: 
> > [requirement]
> > The new shim must be capable of blocking GRUB2.
> > 
> > [result]
> > The new shim is NOT working.
> > 
> > [root cause] 
> > If you compare the new shim codes with the previous one, you can find that
> > upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located
> > in include/sbat.h from "shim,2\ngrub,2\n" to
> > "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data
> > comparison, e.g. component name
> > 
> > [solution]
> > 1) change code back to previous one which is "shim,2\ngrub,2\n"
> > 2) set default sbat policy to "latest", rather than "previous"
> > 3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to
> > avoid shim module itself from sbat blocking. (I'm not sure the functionality
> > of data/sbat.vendor.csv is similar to data/sbat.csv)
> > 4) after changing above 3 points, I can successfully block GRUB2 now:
>                                                                         
> I just add a SUSE specific patch
> shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch to change
> SBAT_VARs to:

@Dennis
Hi Dennis,
I have built new shim with shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/shim

Could you please help to test it?
Comment 40 Michael Chang 2022-05-10 08:51:52 UTC
(In reply to Joey Lee from comment #38)
> (In reply to Tseng from comment #37)
> > (In reply to Joey Lee from comment #36)
> [...snip]
> > 
> > SBAT testing: 
> > [requirement]
> > The new shim must be capable of blocking GRUB2.
> > 
> > [result]
> > The new shim is NOT working.
> > 
> > [root cause] 
> > If you compare the new shim codes with the previous one, you can find that
> > upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located
> > in include/sbat.h from "shim,2\ngrub,2\n" to
> > "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data
> > comparison, e.g. component name
> > 
> > [solution]
> > 1) change code back to previous one which is "shim,2\ngrub,2\n"
> > 2) set default sbat policy to "latest", rather than "previous"
> > 3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to
> > avoid shim module itself from sbat blocking. (I'm not sure the functionality
> > of data/sbat.vendor.csv is similar to data/sbat.csv)
> > 4) after changing above 3 points, I can successfully block GRUB2 now:
>                                                                         
> I just add a SUSE specific patch
> shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch to change
> SBAT_VARs to:
> 
>         SBAT_VAR_PREVIOUS = sbat,1,2021030218\n
>         SBAT_VAR_LATEST = sbat,1,2022050100\nshim.sle,2\ngrub.sle,2\n
>                         = sbat,1,2022050100
>                           shim.sle,2
>                           grub.sle,2

IMHO we should use SBAT_VAR_LATEST = sbat,1,2022050100\nshim,2\ngrub,2\n as long as this round of security update is originated/conducted by upstream.

The grub.sle and shim.sle are used to revoke local patches or mistakes that is post release of upstream's generation. And once after upstream has bumped generation number it will be reset to 0 again as well.

Thanks.
Comment 41 Michael Chang 2022-05-10 09:20:46 UTC
(In reply to Michael Chang from comment #40)
> (In reply to Joey Lee from comment #38)
> > (In reply to Tseng from comment #37)
> > > (In reply to Joey Lee from comment #36)

[snip]

> The grub.sle and shim.sle are used to revoke local patches or mistakes that
> is post release of upstream's generation. And once after upstream has bumped
> generation number it will be reset to 0 again as well.

Sorry. Correct some typo here. The distribution generation can be "reset to 1 or dropped" after major upstream generation has bumped it's number and released.
Comment 42 Joey Lee 2022-05-10 09:54:49 UTC
Hi Michael, 

Thanks for your suggestion.

(In reply to Michael Chang from comment #40)
> (In reply to Joey Lee from comment #38)
> > (In reply to Tseng from comment #37)
> > > (In reply to Joey Lee from comment #36)
> > [...snip]
> > > 
> > > SBAT testing: 
> > > [requirement]
> > > The new shim must be capable of blocking GRUB2.
> > > 
> > > [result]
> > > The new shim is NOT working.
> > > 
> > > [root cause] 
> > > If you compare the new shim codes with the previous one, you can find that
> > > upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located
> > > in include/sbat.h from "shim,2\ngrub,2\n" to
> > > "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data
> > > comparison, e.g. component name
> > > 
> > > [solution]
> > > 1) change code back to previous one which is "shim,2\ngrub,2\n"
> > > 2) set default sbat policy to "latest", rather than "previous"
> > > 3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to
> > > avoid shim module itself from sbat blocking. (I'm not sure the functionality
> > > of data/sbat.vendor.csv is similar to data/sbat.csv)
> > > 4) after changing above 3 points, I can successfully block GRUB2 now:
> >                                                                         
> > I just add a SUSE specific patch
> > shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch to change
> > SBAT_VARs to:
> > 
> >         SBAT_VAR_PREVIOUS = sbat,1,2021030218\n
> >         SBAT_VAR_LATEST = sbat,1,2022050100\nshim.sle,2\ngrub.sle,2\n
> >                         = sbat,1,2022050100
> >                           shim.sle,2
> >                           grub.sle,2
> 
> IMHO we should use SBAT_VAR_LATEST = sbat,1,2022050100\nshim,2\ngrub,2\n as
> long as this round of security update is originated/conducted by upstream.
> 
> The grub.sle and shim.sle are used to revoke local patches or mistakes that
> is post release of upstream's generation. And once after upstream has bumped
> generation number it will be reset to 0 again as well.
> 

Understood. But the upstream shim's generation number is defined in data/sbat.csv and it didn't change to "2" yet. So I prefer to keep the generation number align. I will change the SBAT_VAR_LATEST to:

    SBAT_VAR_LATEST = sbat,1,2022050100\nshim,1\nshim.sle,2\ngrub.sle,2\n
                    = sbat,1,2022050100
                      shim,1
                      shim.sle,2
                      grub,2

How do you think?
Comment 43 Joey Lee 2022-05-10 10:11:03 UTC
(In reply to Joey Lee from comment #42)
> Hi Michael, 
[...snip]
> > 
> > IMHO we should use SBAT_VAR_LATEST = sbat,1,2022050100\nshim,2\ngrub,2\n as
> > long as this round of security update is originated/conducted by upstream.
> > 
> > The grub.sle and shim.sle are used to revoke local patches or mistakes that
> > is post release of upstream's generation. And once after upstream has bumped
> > generation number it will be reset to 0 again as well.
> > 
> 
> Understood. But the upstream shim's generation number is defined in
> data/sbat.csv and it didn't change to "2" yet. So I prefer to keep the
> generation number align. I will change the SBAT_VAR_LATEST to:
> 
>     SBAT_VAR_LATEST = sbat,1,2022050100\nshim,1\nshim.sle,2\ngrub.sle,2\n
>                     = sbat,1,2022050100
>                       shim,1
>                       shim.sle,2
>                       grub,2
> 
> How do you think?

Actually the "shim,1" rule is redundant. So:

    SBAT_VAR_LATEST = sbat,1,2022050100\nshim.sle,2\ngrub.sle,2\n
                    = sbat,1,2022050100
                      shim.sle,2
                      grub,2
Comment 44 Tseng 2022-05-11 01:54:43 UTC
(In reply to Joey Lee from comment #39)
> (In reply to Joey Lee from comment #38)
> > (In reply to Tseng from comment #37)
> > > (In reply to Joey Lee from comment #36)
> > [...snip]
> > > 
> > > SBAT testing: 
> > > [requirement]
> > > The new shim must be capable of blocking GRUB2.
> > > 
> > > [result]
> > > The new shim is NOT working.
> > > 
> > > [root cause] 
> > > If you compare the new shim codes with the previous one, you can find that
> > > upstream has changed the definition of SBAT_VAR_LATEST_REVOCATIONS located
> > > in include/sbat.h from "shim,2\ngrub,2\n" to
> > > "component,2\nothercomponent,2\n" which is not good for GRUB2 meta data
> > > comparison, e.g. component name
> > > 
> > > [solution]
> > > 1) change code back to previous one which is "shim,2\ngrub,2\n"
> > > 2) set default sbat policy to "latest", rather than "previous"
> > > 3) change data/sbat.csv from "shim,1,..." to "shim,2,..." This is used to
> > > avoid shim module itself from sbat blocking. (I'm not sure the functionality
> > > of data/sbat.vendor.csv is similar to data/sbat.csv)
> > > 4) after changing above 3 points, I can successfully block GRUB2 now:
> >                                                                         
> > I just add a SUSE specific patch
> > shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch to change
> > SBAT_VARs to:
> 
> @Dennis
> Hi Dennis,
> I have built new shim with
> shim-sbat-change-the-sbat_var-before-shipping-SUSE-shim.patch in my home
> branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/shim
> 
> Could you please help to test it?

(I've already submitted my test result last night, but I cannot find it this morning. I don't know why ? Anyway, please let me show it again.)

[sbat testing result]
New shim is working well now.

[details]
1) configure to "latest" first, and then back to "previous"
2) shim check:
   For .sbat component name - "shim" : not found in variable, so success (O)
   For .sbat component name - "shim.sle" : generation number(2) = variable(2), so success (O)
3) grub2 check:
   For .sbat component name - "grub" : generation number(1) < variable(2), so grub2 is revoked here. 
   For .sbat component name - "grub.sle" : no chance to compare.
Comment 45 Michael Chang 2022-05-11 07:16:47 UTC
Created attachment 858812 [details]
fix-CVE-2022-28737.tar.gz

aka upate-sbat-v2.tar.gz, somehow they renamed the branch to fix-CVE-2022-28737.

A brief summary in keybase:

> 5d93988 Update SBAT generation requirements for 05/24/22
> e224bc6 SBAT revocation management
> fa0077a Update advertised sbat generation number for shim
> 
> The first one updates shims advertised generation numer to 2.
> 
> The second is the public PR: https://github.com/rhboot/shim/pull/467 ...
> 
> The third adds a set of latest revocation data the requires both shim and grub to > be at generation 2.
> 
> Obviously this needs to be installed in conjunction with an updated GRUB that has > the proper generation number supplied during the build.
Comment 46 Michael Chang 2022-05-11 07:24:17 UTC
(In reply to Joey Lee from comment #42)
[snip]
> Understood. But the upstream shim's generation number is defined in
> data/sbat.csv and it didn't change to "2" yet. So I prefer to keep the
> generation number align. I will change the SBAT_VAR_LATEST to:
> 
>     SBAT_VAR_LATEST = sbat,1,2022050100\nshim,1\nshim.sle,2\ngrub.sle,2\n
>                     = sbat,1,2022050100
>                       shim,1
>                       shim.sle,2
>                       grub,2
> 
> How do you think?

Please check attachment 858812 [details] in which data/sbat.csv has been updated. I supposed  we can drop our specific patch because upstream has addressed them properly.
Thanks.
Comment 47 Michael Chang 2022-05-11 07:57:41 UTC
Created attachment 858815 [details]
grub2.cve_2021_3695.disclosure.txt

*Current* draft for disclosure requirement in grub and shim.
Comment 48 Tseng 2022-05-12 02:57:09 UTC
(In reply to Joey Lee from comment #33)
> (In reply to Michael Chang from comment #15)
> > Created attachment 858423 [details]
> > mokutil: set-sbat-v1.tar.gz
> > 
> 
> Backported to mokutil 0.5.0 for 15-SP4:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/mokutil

[mokutil CLI issue]
Help messages are not lined up exactly.

  --set-verbosity <true/false>          Set the verbosity bit for shim
  --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
  --set-fallback-noreboot <true/false>          Prevent fallback from ..
  --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
  --pk                                  List the keys in PK
  --kek                                 List the keys in KEK
  --db                                  List the keys in db
  --dbx                                 List the keys in dbx
  --timeout <-1,0..0x7fff>              Set the timeout for MOK prompt
  --list-sbat-revocations                               List the entries ..
Comment 49 Joey Lee 2022-05-12 05:26:24 UTC
Hi Michael,

(In reply to Michael Chang from comment #45)
> Created attachment 858812 [details]
> fix-CVE-2022-28737.tar.gz
> 
> aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> fix-CVE-2022-28737.
> 

I didn't see changes comparing with the update-sbat-v1 patches. Could you please confirm?

> A brief summary in keybase:
> 
> > 5d93988 Update SBAT generation requirements for 05/24/22
> > e224bc6 SBAT revocation management
> > fa0077a Update advertised sbat generation number for shim
> > 
> > The first one updates shims advertised generation numer to 2.
> > 
> > The second is the public PR: https://github.com/rhboot/shim/pull/467 ...
> > 
> > The third adds a set of latest revocation data the requires both shim and grub to > be at generation 2.
> > 
> > Obviously this needs to be installed in conjunction with an updated GRUB that has > the proper generation number supplied during the build.

Could you please access the keybase git for the first and third patches (5d93988 and fa0077a)?

Thanks!
Comment 50 Michael Chang 2022-05-12 07:08:03 UTC
(In reply to Joey Lee from comment #49)
> Hi Michael,
> 
> (In reply to Michael Chang from comment #45)
> > Created attachment 858812 [details]
> > fix-CVE-2022-28737.tar.gz
> > 
> > aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> > fix-CVE-2022-28737.
> > 
> 
> I didn't see changes comparing with the update-sbat-v1 patches. Could you
> please confirm?


It is weird. I just have downloaded them to check and they looked different.

> mchang@mazu:~/Downloads> tar xvf upate-sbat-v1.tar.gz
> upate-sbat-v1/
> upate-sbat-v1/0003-SBAT-revocation-update-support.patch
> upate-sbat-v1/0001-MokManager-removed-Locate-graphic-output-protocol-fa.patch
> upate-sbat-v1/0002-shim-implement-SBAT-verification-for-the-shim_lock-p.patch
> mchang@mazu:~/Downloads> tar xvf fix-CVE-2022-28737.tar.gz
> fix-CVE-2022-28737/
> fix-CVE-2022-28737/0005-pe-Perform-image-verification-earlier-when-loading-g.patch
> fix-CVE-2022-28737/0007-SBAT-revocation-management.patch
> fix-CVE-2022-28737/0003-post-process-pe-Fix-a-missing-return-code-check.patch
> fix-CVE-2022-28737/0001-MokManager-removed-Locate-graphic-output-protocol-fa.patch
> fix-CVE-2022-28737/0002-shim-implement-SBAT-verification-for-the-shim_lock-p.patch
> fix-CVE-2022-28737/0004-pe-Fix-a-buffer-overflow-when-SizeOfRawData-VirtualS.patch
> fix-CVE-2022-28737/0008-Update-SBAT-generation-requirements-for-05-24-22.patch
> fix-CVE-2022-28737/0006-Update-advertised-sbat-generation-number-for-shim.patch

> 
> > A brief summary in keybase:
> > 
> > > 5d93988 Update SBAT generation requirements for 05/24/22
> > > e224bc6 SBAT revocation management
> > > fa0077a Update advertised sbat generation number for shim
> > > 
> > > The first one updates shims advertised generation numer to 2.
> > > 
> > > The second is the public PR: https://github.com/rhboot/shim/pull/467 ...
> > > 
> > > The third adds a set of latest revocation data the requires both shim and grub to > be at generation 2.
> > > 
> > > Obviously this needs to be installed in conjunction with an updated GRUB that has > the proper generation number supplied during the build.
> 
> Could you please access the keybase git for the first and third patches
> (5d93988 and fa0077a)?

They are already included in the tarball.

> mchang@mazu:~/Downloads> grep 5d93988 fix-CVE-2022-28737/*.patch
> fix-CVE-2022-28737/0008-Update-SBAT-generation-requirements-for-05-24-22.patch:From 5d93988c338ebf37f9f062fac1900f4dbd005a4f Mon Sep 17 00:00:00 2001
> mchang@mazu:~/Downloads> grep fa0077a fix-CVE-2022-28737/*.patch
> fix-CVE-2022-28737/0006-Update-advertised-sbat-generation-number-for-shim.patch:From fa0077a7c4a5b1c33f24970a3a19d9bc2ff4acca Mon Sep 17 00:00:00 2001
> mchang@mazu:~/Downloads> grep e224bc6 fix-CVE-2022-28737/*.patch
> fix-CVE-2022-28737/0007-SBAT-revocation-management.patch:From e224bc636efb178d945286bff9413a6f5eec4514 Mon Sep 17 00:00:00 2001

Honestly I have no idea what could go wrong here ??

> 
> Thanks!
Comment 51 Joey Lee 2022-05-12 09:01:56 UTC
(In reply to Michael Chang from comment #50)
> (In reply to Joey Lee from comment #49)
> > Hi Michael,
> > 
> > (In reply to Michael Chang from comment #45)
> > > Created attachment 858812 [details]
> > > fix-CVE-2022-28737.tar.gz
> > > 
> > > aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> > > fix-CVE-2022-28737.
> > > 
> > 
> > I didn't see changes comparing with the update-sbat-v1 patches. Could you
> > please confirm?
> 
> 
> It is weird. I just have downloaded them to check and they looked different.
> 
> > mchang@mazu:~/Downloads> tar xvf upate-sbat-v1.tar.gz
> > upate-sbat-v1/
> > upate-sbat-v1/0003-SBAT-revocation-update-support.patch
> > upate-sbat-v1/0001-MokManager-removed-Locate-graphic-output-protocol-fa.patch
> > upate-sbat-v1/0002-shim-implement-SBAT-verification-for-the-shim_lock-p.patch
> > mchang@mazu:~/Downloads> tar xvf fix-CVE-2022-28737.tar.gz
> > fix-CVE-2022-28737/
> > fix-CVE-2022-28737/0005-pe-Perform-image-verification-earlier-when-loading-g.patch
> > fix-CVE-2022-28737/0007-SBAT-revocation-management.patch
> > fix-CVE-2022-28737/0003-post-process-pe-Fix-a-missing-return-code-check.patch
> > fix-CVE-2022-28737/0001-MokManager-removed-Locate-graphic-output-protocol-fa.patch
> > fix-CVE-2022-28737/0002-shim-implement-SBAT-verification-for-the-shim_lock-p.patch
> > fix-CVE-2022-28737/0004-pe-Fix-a-buffer-overflow-when-SizeOfRawData-VirtualS.patch
> > fix-CVE-2022-28737/0008-Update-SBAT-generation-requirements-for-05-24-22.patch
> > fix-CVE-2022-28737/0006-Update-advertised-sbat-generation-number-for-shim.patch
> 

Sorry for I just copy and open a wrong tarball. I downloaded fix-CVE-2022-28737.tar.gz again and I saw those patches now.

Thanks!
Comment 52 Joey Lee 2022-05-12 15:37:11 UTC
(In reply to Michael Chang from comment #45)
> Created attachment 858812 [details]
> fix-CVE-2022-28737.tar.gz
> 
> aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> fix-CVE-2022-28737.

Thanks for Michael's new tarball. I have updated 15-SP4 shim in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/shim

I will also update openSUSE:Factory shim tomorrow.
Comment 53 Joey Lee 2022-05-13 05:37:16 UTC
(In reply to Joey Lee from comment #52)
> (In reply to Michael Chang from comment #45)
> > Created attachment 858812 [details]
> > fix-CVE-2022-28737.tar.gz
> > 
> > aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> > fix-CVE-2022-28737.
> 
> Thanks for Michael's new tarball. I have updated 15-SP4 shim in my home
> branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update/shim
> 
> I will also update openSUSE:Factory shim tomorrow.

I have also updated openSUSE:Factory shim in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:openSUSE:Factory/shim

@Dennis
Please help to test it.
Comment 54 Joey Lee 2022-05-13 05:50:25 UTC
(In reply to Tseng from comment #48)
> (In reply to Joey Lee from comment #33)
> > (In reply to Michael Chang from comment #15)
> > > Created attachment 858423 [details]
> > > mokutil: set-sbat-v1.tar.gz
> > > 
> > 
> > Backported to mokutil 0.5.0 for 15-SP4:
> > 
> > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update/mokutil
> 
> [mokutil CLI issue]
> Help messages are not lined up exactly.
> 
>   --set-verbosity <true/false>          Set the verbosity bit for shim
>   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
>   --set-fallback-noreboot <true/false>          Prevent fallback from ..
>   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..

Because this problem is minor, so I will keep it until upstream changed.
Comment 55 Joey Lee 2022-05-13 06:07:23 UTC
Dennis's test result of shim self-check mechanism. Which means that the generation.1 shim will be revoked (self-blocked) after generation.2 shim be installed on target system.

Dennis's result:

>Could you please help to test the old shim can be revoked after a new shim be
installed?
Sure. The testing result shows that the new shim can revoke the old shim, as we
expected.

[.sbat section]
sbat, 1, SBAT Version, sbat, 1, https://github.com/rhboot/shim/blob/main/
SBAT.md
shim, 1, UEFI shim, shim, 1, https://github.com/rhboot/shim
shim.sle, 1, SUSE Linux Enterprise, shim, 15.5, mail:security-team@suse.de

[result]
section-gen(1) < var-gen(2) when comparing shim.sle component name.
component shim.sle/generation 1, was revoked by SbatLevel variable
image did not pass SBAT verification
Verifiying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy
Violation

BR//Dennis
Comment 56 Tseng 2022-05-14 12:00:19 UTC
(In reply to Joey Lee from comment #53)
> (In reply to Joey Lee from comment #52)
> > (In reply to Michael Chang from comment #45)
> > > Created attachment 858812 [details]
> > > fix-CVE-2022-28737.tar.gz
> > > 
> > > aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> > > fix-CVE-2022-28737.
> > 
> > Thanks for Michael's new tarball. I have updated 15-SP4 shim in my home
> > branch on IBS:
> > 
> > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update/shim
> > 
> > I will also update openSUSE:Factory shim tomorrow.
> 
> I have also updated openSUSE:Factory shim in my home branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:
> openSUSE:Factory/shim
> 
> @Dennis
> Please help to test it.

Sure. The new shim with patches from Michael's new tarball is working very well.
[details]
- for shim module checking: success
  .sbat's sbat component = variable's sbat component, and both generation numbers are equal to 1.
  .sbat's shim component = variable's shim component, and both generation number s are equl to 2.
  .sbat's shim.opensuse component is not found in variable entries, so success.

- for grub module checking: revoked
  .sbat's sbat component = variable's sbat component, and both generation numbers are equal to 1.
  .sbat's grub component = variable's grub component, but generation number(1) < (2), so grub is revoked.
  component grub/generation 1, was revoked by SbatLevel variable
  image did not pass SBAT verification
Comment 57 Marcus Meissner 2022-05-16 09:13:57 UTC
New CRD was set to allow shim code to be ready.

CRD: 2022-06-07 10:00PT
Comment 58 Joey Lee 2022-05-19 13:42:35 UTC
Base on email discussion, I have added "mokutil --set-sbat-policy latest" command to the post script in shim RPM. The new package is in my home branch:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update/shim

When the SbatPolicy variable does not exist. The post script will generate and set the policy to latest mode. The post script likes this:

# copy from kernel-scriptlets/cert-script
is_efi () {
    local msg rc=0
# The below statement fails if mokutil isn't installed or UEFI is unsupported.
# It doesn't fail if UEFI is available but secure boot is off.
    msg="$(mokutil --sb-state 2>&1)" || rc=$?
    return $rc
}
# run mokutil for setting sbat policy to latest mode
SBAT_POLICY=/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23
if is_efi; then
        if [ ! -f "$SBAT_POLICY" ]; then
                mokutil --set-sbat-policy latest
        fi
fi
Comment 59 Tseng 2022-05-20 08:57:50 UTC
(In reply to Joey Lee from comment #54)
> (In reply to Tseng from comment #48)
> > (In reply to Joey Lee from comment #33)
> > > (In reply to Michael Chang from comment #15)
> > > > Created attachment 858423 [details]
> > > > mokutil: set-sbat-v1.tar.gz
> > > > 
> > > 
> > > Backported to mokutil 0.5.0 for 15-SP4:
> > > 
> > > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > > Update/mokutil
> > 
> > [mokutil CLI issue]
> > Help messages are not lined up exactly.
> > 
> >   --set-verbosity <true/false>          Set the verbosity bit for shim
> >   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
> >   --set-fallback-noreboot <true/false>          Prevent fallback from ..
> >   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
> 
> Because this problem is minor, so I will keep it until upstream changed.

[mokutil core dump]
When user keys in an unknown option, OS will show "Abort(core dump)"

For example:
"mokutil -sb-state" is incorrect. Rather, "mokutil --sb-state" is correct.

This is because, in switch...case of mokutil.c, default function - abort() is called. 
default:
   abort(); //popular

[suggestion]
default:
   usage(argv[0]);
   exit(EXIT_FAILURE);
Comment 60 Joey Lee 2022-05-20 12:44:39 UTC
Hi Dennis,

(In reply to Tseng from comment #59)
> (In reply to Joey Lee from comment #54)
> > (In reply to Tseng from comment #48)
> > > (In reply to Joey Lee from comment #33)
> > > > (In reply to Michael Chang from comment #15)
> > > > > Created attachment 858423 [details]
> > > > > mokutil: set-sbat-v1.tar.gz
> > > > > 
> > > > 
> > > > Backported to mokutil 0.5.0 for 15-SP4:
> > > > 
> > > > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > > > Update/mokutil
> > > 
> > > [mokutil CLI issue]
> > > Help messages are not lined up exactly.
> > > 
> > >   --set-verbosity <true/false>          Set the verbosity bit for shim
> > >   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
> > >   --set-fallback-noreboot <true/false>          Prevent fallback from ..
> > >   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
> > 
> > Because this problem is minor, so I will keep it until upstream changed.
> 
> [mokutil core dump]
> When user keys in an unknown option, OS will show "Abort(core dump)"
> 
> For example:
> "mokutil -sb-state" is incorrect. Rather, "mokutil --sb-state" is correct.
> 
> This is because, in switch...case of mokutil.c, default function - abort()
> is called. 
> default:
>    abort(); //popular
> 
> [suggestion]
> default:
>    usage(argv[0]);
>    exit(EXIT_FAILURE);

Could you please send patch to mokutil upstream? Let's work on upstream also.

Thanks!
Comment 61 Tseng 2022-05-23 02:20:38 UTC
(In reply to Michael Chang from comment #45)
> Created attachment 858812 [details]
> fix-CVE-2022-28737.tar.gz
> 
> aka upate-sbat-v2.tar.gz, somehow they renamed the branch to
> fix-CVE-2022-28737.
> 
> A brief summary in keybase:
> 
> > 5d93988 Update SBAT generation requirements for 05/24/22
> > e224bc6 SBAT revocation management
> > fa0077a Update advertised sbat generation number for shim
> > 
> > The first one updates shims advertised generation numer to 2.
> > 
> > The second is the public PR: https://github.com/rhboot/shim/pull/467 ...
> > 
> > The third adds a set of latest revocation data the requires both shim and grub to > be at generation 2.
> > 
> > Obviously this needs to be installed in conjunction with an updated GRUB that has > the proper generation number supplied during the build.

[test result for fix-CVE-2022-28737/0004-pe-Fix-a-buffer-overflow-when-SizeOfRawData-VirtualS.patch]

[details]
(In reply to Joey Lee from comment #60)
> Hi Dennis,
> 
> (In reply to Tseng from comment #59)
> > (In reply to Joey Lee from comment #54)
> > > (In reply to Tseng from comment #48)
> > > > (In reply to Joey Lee from comment #33)
> > > > > (In reply to Michael Chang from comment #15)
> > > > > > Created attachment 858423 [details]
> > > > > > mokutil: set-sbat-v1.tar.gz
> > > > > > 
> > > > > 
> > > > > Backported to mokutil 0.5.0 for 15-SP4:
> > > > > 
> > > > > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > > > > Update/mokutil
> > > > 
> > > > [mokutil CLI issue]
> > > > Help messages are not lined up exactly.
> > > > 
> > > >   --set-verbosity <true/false>          Set the verbosity bit for shim
> > > >   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
> > > >   --set-fallback-noreboot <true/false>          Prevent fallback from ..
> > > >   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
> > > 
> > > Because this problem is minor, so I will keep it until upstream changed.
> > 
> > [mokutil core dump]
> > When user keys in an unknown option, OS will show "Abort(core dump)"
> > 
> > For example:
> > "mokutil -sb-state" is incorrect. Rather, "mokutil --sb-state" is correct.
> > 
> > This is because, in switch...case of mokutil.c, default function - abort()
> > is called. 
> > default:
> >    abort(); //popular
> > 
> > [suggestion]
> > default:
> >    usage(argv[0]);
> >    exit(EXIT_FAILURE);
> 
> Could you please send patch to mokutil upstream? Let's work on upstream also.
> 
> Thanks!

Sure. I will do it. BTW, I also tested the fix-CVE-2022-28737/0004-pe-Fix-a-buffer-overflow-when-SizeOfRawData-VirtualS.patch

[test result]
system crashes when VirtualSize < SizeOfRawData. (to be confirmed)

!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
RIP  - 0000000005B1C078, CS  - 0000000000000038, RFLAGS - 0000000000200286
RAX  - 0000000005B1B105, RCX - 0000000000000005, RDX - 0000000005B1D606
RBX  - 0000000005B19D3A, RSP - 0000000005B21488, RBP - 20656D6F636C6557
RSI  - 00000000000000FF, RDI - 0000000005B21480
R8   - 0025200300200001, R9  - 0000000007E8D28F, R10 - 00000000801A2D40
R11  - 000000000009D35F, R12 - 0000000005B1D5F3, R13 - 0000000005B21480
R14  - 0000000005B19843, R15 - 0000000005E12DE0
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000079EE698 0000000000000047, LDTR - 0000000000000000
IDTR - 00000000072F7018 0000000000000FFF,   TR - 0000000000000000

[steps]
1) change the 9th,10th bytes(VirtualSize) of section 0 of grub2 image from 0xC000(49152) to 0xB000(45056).

old image:
0000:  2E 74 65 78 74 00 00 00  00 C0 00 00 00 10 00 00    .text...........                    
0010:  00 C0 00 00 00 10 00 00  00 00 00 00 00 00 00 00    ................                    
0020:  00 00 00 00 20 00 00 60  2E 64 61 74 61 00 00 00    .......`.data...                    

new one:
0000:  2E 74 65 78 74 00 00 00  00 B0 00 00 00 10 00 00    .text...........                    
0010:  00 C0 00 00 00 10 00 00  00 00 00 00 00 00 00 00    ................                    
0020:  00 00 00 00 20 00 00 60  2E 64 61 74 61 00 00 00    .......`.data...                    
0030:  00 00 01 00 00 D0 00 00  00 00 01 00 00 D0 00 00    ................

2) run shim.efi

[comments]
The patch's logic is correct in which the smaller size data, either VirtualSize or SizeOfRawData, is copied, but this might result in incomplete RawData. I need more time to confirm it.

patch codes:
size = Section->Misc.VirtualSize;
if (size > Section->SizeOfRawData)
    size = Section->SizeOfRawData;
if (size > 0)
    CopyMem(base, data + Section->PointerToRawData, size);
Comment 62 Joey Lee 2022-05-23 06:28:21 UTC
In case we need new shim against this issue. I have pushed newest shim (latest commit id: a78673b19e98b) to my home branch on IBS:

https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update-15.5+

For building aarch64 image, the objcopy in binutils needs to support efi-*-aarch64 for new shim. So I backported 3 patches to binutils.

Unfortunately this newest shim can not boot with SUSE grub2. The grub2 menu can not show up and fall into grub2 command line prompt.

I have bisect grub2 15.5..a78673b19e98b, looks acfd48f45b9 upstream patch causes this problem. I am still looking at it.
Comment 63 Joey Lee 2022-05-23 06:31:21 UTC
(In reply to Joey Lee from comment #62)
> In case we need new shim against this issue. I have pushed newest shim
> (latest commit id: a78673b19e98b) to my home branch on IBS:
> 
> https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update-15.5+

Update the above link because "+" character doesn't work on bugzilla:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update-15.5+/shim

> 
> For building aarch64 image, the objcopy in binutils needs to support
> efi-*-aarch64 for new shim. So I backported 3 patches to binutils.
> 
> Unfortunately this newest shim can not boot with SUSE grub2. The grub2 menu
> can not show up and fall into grub2 command line prompt.
> 
> I have bisect grub2 15.5..a78673b19e98b, looks acfd48f45b9 upstream patch
> causes this problem. I am still looking at it.
Comment 64 Michael Chang 2022-05-23 08:22:07 UTC
(In reply to Joey Lee from comment #62)
> In case we need new shim against this issue. I have pushed newest shim
> (latest commit id: a78673b19e98b) to my home branch on IBS:
> 
> https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update-15.5+
> 
> For building aarch64 image, the objcopy in binutils needs to support
> efi-*-aarch64 for new shim. So I backported 3 patches to binutils.
> 
> Unfortunately this newest shim can not boot with SUSE grub2. The grub2 menu
> can not show up and fall into grub2 command line prompt.

Looks like grub couldn't get it's bootpath from LoadedImage ?

> 
> I have bisect grub2 15.5..a78673b19e98b, looks acfd48f45b9 upstream patch
> causes this problem. I am still looking at it.

Is it grub or shim ? Grub has no 15.5 while shim does. Would you please help to clarify this grub issue or not as I am confused ? Thanks.
Comment 65 Joey Lee 2022-05-25 01:36:11 UTC
(In reply to Michael Chang from comment #64)
> (In reply to Joey Lee from comment #62)
> > In case we need new shim against this issue. I have pushed newest shim
> > (latest commit id: a78673b19e98b) to my home branch on IBS:
> > 
> > https://build.suse.de/project/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update-15.5+
> > 
> > For building aarch64 image, the objcopy in binutils needs to support
> > efi-*-aarch64 for new shim. So I backported 3 patches to binutils.
> > 
> > Unfortunately this newest shim can not boot with SUSE grub2. The grub2 menu
> > can not show up and fall into grub2 command line prompt.
> 
> Looks like grub couldn't get it's bootpath from LoadedImage ?
> 

The shim 15.6-rc1 is released now. I think that this patch can fix the problem:

From 5d789ca4cd9121d81357b0edb75f500dfdcc9ab7 Mon Sep 17 00:00:00 2001                    From: Peter Jones <pjones@redhat.com>                                                     Date: Wed, 18 May 2022 15:13:47 -0400                                                     Subject: [PATCH] Always initialize data/datasize before calling read_image()              scan-build noticed that there's a path where we'll pass some data from                    the read_image() to e.g. the string functions, but it might be an                         unassigned pointer on one of the code paths.  I don't think you can                       actually hit it without returning from an error first, but best to                        initialize these anyway.                                                                  This patch initializes data to NULL and datasize to 0.

I will check it later.

> > 
> > I have bisect grub2 15.5..a78673b19e98b, looks acfd48f45b9 upstream patch
> > causes this problem. I am still looking at it.
> 
> Is it grub or shim ? Grub has no 15.5 while shim does. Would you please help
> to clarify this grub issue or not as I am confused ? Thanks.

Sorry for my typo. It's shim 15.5.
Comment 66 Michael Chang 2022-05-25 04:16:25 UTC
Created attachment 859201 [details]
fix-CVE-2022-28737-v4.tar.gz

Hi Joey and Dennis,

Please check attached tarball which contains patch files from fix-CVE-2022-28737-v4 branch of shim. They are based on master branch commit: 

> 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot

Thanks.
Comment 67 Joey Lee 2022-05-25 13:01:37 UTC
(In reply to Michael Chang from comment #66)
> Created attachment 859201 [details]
> fix-CVE-2022-28737-v4.tar.gz
> 
> Hi Joey and Dennis,
> 
> Please check attached tarball which contains patch files from
> fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> commit: 
> 
> > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> 
> Thanks.

I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu" problem. I will base on it to port the v4 patches.
Comment 68 Joey Lee 2022-05-26 02:11:43 UTC
(In reply to Joey Lee from comment #67)
> (In reply to Michael Chang from comment #66)
> > Created attachment 859201 [details]
> > fix-CVE-2022-28737-v4.tar.gz
> > 
> > Hi Joey and Dennis,
> > 
> > Please check attached tarball which contains patch files from
> > fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> > commit: 
> > 
> > > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> > 
> > Thanks.
> 
> I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu"
> problem. I will base on it to port the v4 patches.

I build fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update-15.5+v2/shim

@Dennis
Could you please help to test it? Please also test aarch64 version because the objcopy has changed in this time.

Thanks!
Comment 69 Tseng 2022-05-26 13:46:30 UTC
(In reply to Joey Lee from comment #68)
> (In reply to Joey Lee from comment #67)
> > (In reply to Michael Chang from comment #66)
> > > Created attachment 859201 [details]
> > > fix-CVE-2022-28737-v4.tar.gz
> > > 
> > > Hi Joey and Dennis,
> > > 
> > > Please check attached tarball which contains patch files from
> > > fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> > > commit: 
> > > 
> > > > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> > > 
> > > Thanks.
> > 
> > I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu"
> > problem. I will base on it to port the v4 patches.
> 
> I build fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home
> branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update-15.5+v2/shim
> 
> @Dennis
> Could you please help to test it? Please also test aarch64 version because
> the objcopy has changed in this time.
> 
> Thanks!

Sure. 
[for x86_64]
1) No signatures found.
2) (In reply to Joey Lee from comment #60)
> Hi Dennis,
> 
> (In reply to Tseng from comment #59)
> > (In reply to Joey Lee from comment #54)
> > > (In reply to Tseng from comment #48)
> > > > (In reply to Joey Lee from comment #33)
> > > > > (In reply to Michael Chang from comment #15)
> > > > > > Created attachment 858423 [details]
> > > > > > mokutil: set-sbat-v1.tar.gz
> > > > > > 
> > > > > 
> > > > > Backported to mokutil 0.5.0 for 15-SP4:
> > > > > 
> > > > > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > > > > Update/mokutil
> > > > 
> > > > [mokutil CLI issue]
> > > > Help messages are not lined up exactly.
> > > > 
> > > >   --set-verbosity <true/false>          Set the verbosity bit for shim
> > > >   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
> > > >   --set-fallback-noreboot <true/false>          Prevent fallback from ..
> > > >   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
> > > 
> > > Because this problem is minor, so I will keep it until upstream changed.
> > 
> > [mokutil core dump]
> > When user keys in an unknown option, OS will show "Abort(core dump)"
> > 
> > For example:
> > "mokutil -sb-state" is incorrect. Rather, "mokutil --sb-state" is correct.
> > 
> > This is because, in switch...case of mokutil.c, default function - abort()
> > is called. 
> > default:
> >    abort(); //popular
> > 
> > [suggestion]
> > default:
> >    usage(argv[0]);
> >    exit(EXIT_FAILURE);
> 
> Could you please send patch to mokutil upstream? Let's work on upstream also.
> 
> Thanks!

Upstream has accepted my suggestion, but they changed my codes to :
has been accepted by upstream, but they modified my codes to:

+ default:
      +       command |= HELP;
      +       break;
      - default:
      -       abort ();
     } 

https://github.com/rhboot/mokutil/compare/99d3990bdbbca0419dc97133f27d6932b3234224..873b487b529be93b721aa8db6380628707dac81d
Comment 70 Tseng 2022-05-27 06:25:41 UTC
(In reply to Tseng from comment #69)
> (In reply to Joey Lee from comment #68)
> > (In reply to Joey Lee from comment #67)
> > > (In reply to Michael Chang from comment #66)
> > > > Created attachment 859201 [details]
> > > > fix-CVE-2022-28737-v4.tar.gz
> > > > 
> > > > Hi Joey and Dennis,
> > > > 
> > > > Please check attached tarball which contains patch files from
> > > > fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> > > > commit: 
> > > > 
> > > > > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> > > > 
> > > > Thanks.
> > > 
> > > I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu"
> > > problem. I will base on it to port the v4 patches.
> > 
> > I build fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home
> > branch on IBS:
> > 
> > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update-15.5+v2/shim
> > 
> > @Dennis
> > Could you please help to test it? Please also test aarch64 version because
> > the objcopy has changed in this time.
> > 
> > Thanks!
> 
> Sure. 
> [for x86_64]
> 1) No signatures found.
> 2) (In reply to Joey Lee from comment #60)
> > Hi Dennis,
> > 
> > (In reply to Tseng from comment #59)
> > > (In reply to Joey Lee from comment #54)
> > > > (In reply to Tseng from comment #48)
> > > > > (In reply to Joey Lee from comment #33)
> > > > > > (In reply to Michael Chang from comment #15)
> > > > > > > Created attachment 858423 [details]
> > > > > > > mokutil: set-sbat-v1.tar.gz
> > > > > > > 
> > > > > > 
> > > > > > Backported to mokutil 0.5.0 for 15-SP4:
> > > > > > 
> > > > > > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > > > > > Update/mokutil
> > > > > 
> > > > > [mokutil CLI issue]
> > > > > Help messages are not lined up exactly.
> > > > > 
> > > > >   --set-verbosity <true/false>          Set the verbosity bit for shim
> > > > >   --set-fallback-verbosity <true/false>         Set the verbosity bit for ..
> > > > >   --set-fallback-noreboot <true/false>          Prevent fallback from ..
> > > > >   --set-sbat-policy <latest/previous/delete>            Apply Latest, ..
> > > > 
> > > > Because this problem is minor, so I will keep it until upstream changed.
> > > 
> > > [mokutil core dump]
> > > When user keys in an unknown option, OS will show "Abort(core dump)"
> > > 
> > > For example:
> > > "mokutil -sb-state" is incorrect. Rather, "mokutil --sb-state" is correct.
> > > 
> > > This is because, in switch...case of mokutil.c, default function - abort()
> > > is called. 
> > > default:
> > >    abort(); //popular
> > > 
> > > [suggestion]
> > > default:
> > >    usage(argv[0]);
> > >    exit(EXIT_FAILURE);
> > 
> > Could you please send patch to mokutil upstream? Let's work on upstream also.
> > 
> > Thanks!
> 
> Upstream has accepted my suggestion, but they changed my codes to :
> has been accepted by upstream, but they modified my codes to:
> 
> + default:
>       +       command |= HELP;
>       +       break;
>       - default:
>       -       abort ();
>      } 
> 
> https://github.com/rhboot/mokutil/compare/
> 99d3990bdbbca0419dc97133f27d6932b3234224..
> 873b487b529be93b721aa8db6380628707dac81d


SLE-15-SP4:Shim-Update-15.5+v2/shim testing for x86_64 :
[result]
sbat is working very well.
[details]
1) run shim.efi in guest. No revocation occurs because the default SbatPolicy='previous' and the current variable's generation number of grub = 1.
2) run mokutil to set SbatPolicy='latest'. Grub2 is revoked now because old Grub2's generation number(1) < variable's generation number(2)
3) run Dennis's SbatPolice-reset program to keep guest OS running again.
4) run mokutil to set SbatPolicy='previous' or 'delete'

SLE-15-SP4:Shim-Update-15.5+v2/shim testing for aarch64 :
still working ...
Comment 71 Joey Lee 2022-05-27 07:58:21 UTC
(In reply to Joey Lee from comment #68)
> (In reply to Joey Lee from comment #67)
> > (In reply to Michael Chang from comment #66)
> > > Created attachment 859201 [details]
> > > fix-CVE-2022-28737-v4.tar.gz
> > > 
> > > Hi Joey and Dennis,
> > > 
> > > Please check attached tarball which contains patch files from
> > > fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> > > commit: 
> > > 
> > > > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> > > 
> > > Thanks.
> > 
> > I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu"
> > problem. I will base on it to port the v4 patches.
> 
> I build fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home
> branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> Update-15.5+v2/shim

I also updated the openSUSE shim to fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home branch on IBS:

https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:openSUSE:Factory/shim

@Dennis
Please help to test it.
Comment 72 Tseng 2022-05-30 05:23:44 UTC
(In reply to Joey Lee from comment #71)
> (In reply to Joey Lee from comment #68)
> > (In reply to Joey Lee from comment #67)
> > > (In reply to Michael Chang from comment #66)
> > > > Created attachment 859201 [details]
> > > > fix-CVE-2022-28737-v4.tar.gz
> > > > 
> > > > Hi Joey and Dennis,
> > > > 
> > > > Please check attached tarball which contains patch files from
> > > > fix-CVE-2022-28737-v4 branch of shim. They are based on master branch
> > > > commit: 
> > > > 
> > > > > 77144e5 (HEAD -> main, origin/main, origin/HEAD) SBAT Policy latest should be a one-shot
> > > > 
> > > > Thanks.
> > > 
> > > I have tested shim-15.6_rc1+77144e5a and it doesn't have the "grub2 menu"
> > > problem. I will base on it to port the v4 patches.
> > 
> > I build fix-CVE-2022-28737-v4 patches with shim-15.6_rc1+77144e5a in my home
> > branch on IBS:
> > 
> > https://build.suse.de/package/show/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-
> > Update-15.5+v2/shim
> 
> I also updated the openSUSE shim to fix-CVE-2022-28737-v4 patches with
> shim-15.6_rc1+77144e5a in my home branch on IBS:
> 
> https://build.suse.de/package/show/home:joeyli:branches:openSUSE.org:
> openSUSE:Factory/shim
> 
> @Dennis
> Please help to test it.

openSUSE version testing (shim-15.6~rc1+77144e5a-0.x86_64.rpm) for x86_64 :
[result]
sbat is working very well.
[details]
1) run shim.efi in guest. No revocation occurs because the default SbatPolicy='previous' and the current variable's generation number of grub = 1.
2) run mokutil-0.5.0 to set SbatPolicy='latest'. Grub2 is revoked now because old Grub2's generation number(1) < variable's generation number(2)
3) run Dennis's SbatPolice-reset program to keep guest OS running again.
4) run mokutil to set SbatPolicy='previous' or 'delete'
Comment 99 Marcus Meissner 2022-06-07 18:14:42 UTC
public npow
Comment 105 Joey Lee 2022-06-09 04:23:16 UTC
Submit request to mokutil to the following SLE versions:

SUSE:SLE-15-SP4
        0.5.0.tar.gz
        https://build.suse.de/request/show/273813
SUSE:SLE-15-SP3:Update
        Inherited from SUSE:SLE-15-SP2:Update
SUSE:SLE-15-SP2
        0.4.0.tar.gz
        https://build.suse.de/request/show/273814
SUSE:SLE-15-SP1:Update
        mokutil-0.3.0.tar.bz2
        https://build.suse.de/request/show/273903
SUSE:SLE-15
        mokutil-0.3.0.tar.bz2
        https://build.suse.de/request/show/273815

SUSE:SLE-12-SP5:Update 
        mokutil-0.2.0.tar.bz2
        https://build.suse.de/request/show/273838
SUSE:SLE-12-SP4:Update
        Inherited from SUSE:SLE-12:Update
SUSE:SLE-12-SP3:Update
        Inherited from SUSE:SLE-12:Update
SUSE:SLE-12-SP2:Update
        Inherited from SUSE:SLE-12:Update
SUSE:SLE-12-SP1:Update
        Inherited from SUSE:SLE-12:Update
SUSE:SLE-12:Update
        mokutil-0.2.0.tar.bz2
        https://build.suse.de/request/show/273820

SUSE:SLE-11-SP4:Update
        Inherited from SUSE:SLE-11-SP3:Update
SUSE:SLE-11-SP3:Update
        mokutil-0.1.0.tar.bz2
        https://build.suse.de/request/show/273821
Comment 111 Michael Matz 2022-06-13 15:53:39 UTC
(In reply to Joey Lee from comment #106)
> 
> Could you please help me to put the following patches to binutils?
> ...
> We need those patches for supporting efi-app-aarch64 target in objcopy.
> Otherwise new aarch64-shim can not be built.

I have prepared the binutils update in ibs://Devel:Toolchain:SLE15/
When you confirm this to be working for you I will submit the maintenance
request.
Comment 112 Joey Lee 2022-06-14 04:45:23 UTC
Hi Michael, 

(In reply to Michael Matz from comment #111)
> (In reply to Joey Lee from comment #106)
> > 
> > Could you please help me to put the following patches to binutils?
> > ...
> > We need those patches for supporting efi-app-aarch64 target in objcopy.
> > Otherwise new aarch64-shim can not be built.
> 
> I have prepared the binutils update in ibs://Devel:Toolchain:SLE15/
> When you confirm this to be working for you I will submit the maintenance
> request.

Thanks for your help! The binutils in Devel:Toolchain:SLE15 works to me to build out aarch64-shim. 

I have branched it to my branch with new 15.6 shim:

https://build.suse.de/project/monitor/home:joeyli:branches:SUSE:SLE-15-SP4:Shim-Update-15.6

It confirmed that the binutils works. Could you please submit to maintenance?
Comment 113 Michael Matz 2022-06-14 11:54:03 UTC
(In reply to Joey Lee from comment #112)
> It confirmed that the binutils works. Could you please submit to maintenance?

Most excellent, thanks!  I've submitted now as SR#274209 .
Comment 115 Joey Lee 2022-06-17 04:47:00 UTC
(In reply to Michael Matz from comment #113)
> (In reply to Joey Lee from comment #112)
> > It confirmed that the binutils works. Could you please submit to maintenance?
> 
> Most excellent, thanks!  I've submitted now as SR#274209 .

Thanks a lot!

I will submit request shim 15.6 to 15-SP4 repo after the above binutils change be merged to 15-SP4.
Comment 117 Swamp Workflow Management 2022-06-22 19:18:10 UTC
SUSE-RU-2022:2157-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.4 (src):    binutils-2.37-150100.7.37.1, bpftrace-0.14.0-150400.3.2.2, cross-aarch64-binutils-2.37-150100.7.37.1, cross-arm-binutils-2.37-150100.7.37.1, cross-avr-binutils-2.37-150100.7.37.1, cross-epiphany-binutils-2.37-150100.7.37.1, cross-hppa-binutils-2.37-150100.7.37.1, cross-hppa64-binutils-2.37-150100.7.37.1, cross-i386-binutils-2.37-150100.7.37.1, cross-ia64-binutils-2.37-150100.7.37.1, cross-m68k-binutils-2.37-150100.7.37.1, cross-mips-binutils-2.37-150100.7.37.1, cross-ppc-binutils-2.37-150100.7.37.1, cross-ppc64-binutils-2.37-150100.7.37.1, cross-ppc64le-binutils-2.37-150100.7.37.1, cross-riscv64-binutils-2.37-150100.7.37.1, cross-rx-binutils-2.37-150100.7.37.1, cross-s390-binutils-2.37-150100.7.37.1, cross-s390x-binutils-2.37-150100.7.37.1, cross-sparc-binutils-2.37-150100.7.37.1, cross-sparc64-binutils-2.37-150100.7.37.1, cross-spu-binutils-2.37-150100.7.37.1, cross-x86_64-binutils-2.37-150100.7.37.1
openSUSE Leap 15.3 (src):    binutils-2.37-150100.7.37.1, bpftrace-0.11.4-150300.3.11.4, cross-aarch64-binutils-2.37-150100.7.37.1, cross-arm-binutils-2.37-150100.7.37.1, cross-avr-binutils-2.37-150100.7.37.1, cross-epiphany-binutils-2.37-150100.7.37.1, cross-hppa-binutils-2.37-150100.7.37.1, cross-hppa64-binutils-2.37-150100.7.37.1, cross-i386-binutils-2.37-150100.7.37.1, cross-ia64-binutils-2.37-150100.7.37.1, cross-m68k-binutils-2.37-150100.7.37.1, cross-mips-binutils-2.37-150100.7.37.1, cross-ppc-binutils-2.37-150100.7.37.1, cross-ppc64-binutils-2.37-150100.7.37.1, cross-ppc64le-binutils-2.37-150100.7.37.1, cross-riscv64-binutils-2.37-150100.7.37.1, cross-rx-binutils-2.37-150100.7.37.1, cross-s390-binutils-2.37-150100.7.37.1, cross-s390x-binutils-2.37-150100.7.37.1, cross-sparc-binutils-2.37-150100.7.37.1, cross-sparc64-binutils-2.37-150100.7.37.1, cross-spu-binutils-2.37-150100.7.37.1, cross-x86_64-binutils-2.37-150100.7.37.1
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP4 (src):    binutils-2.37-150100.7.37.1
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP3 (src):    binutils-2.37-150100.7.37.1
SUSE Linux Enterprise Module for Development Tools 15-SP4 (src):    binutils-2.37-150100.7.37.1, bpftrace-0.14.0-150400.3.2.2
SUSE Linux Enterprise Module for Development Tools 15-SP3 (src):    binutils-2.37-150100.7.37.1, bpftrace-0.11.4-150300.3.11.4
SUSE Linux Enterprise Module for Basesystem 15-SP4 (src):    binutils-2.37-150100.7.37.1
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    binutils-2.37-150100.7.37.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 118 Joey Lee 2022-06-27 08:33:19 UTC
The updated binutils be merged. So I have submitreq shim 15.6 to 15-SP3 update repo:

https://build.suse.de/request/show/274886
Comment 119 Joey Lee 2022-06-28 06:03:09 UTC
(In reply to Joey Lee from comment #118)
> The updated binutils be merged. So I have submitreq shim 15.6 to 15-SP3
> update repo:
> 
> https://build.suse.de/request/show/274886

Also submitreq to openSUSE:Factory on OBS:

https://build.opensuse.org/request/show/985419
Comment 120 Marcus Meissner 2022-06-28 08:26:12 UTC
SLE one is in 
SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update
Comment 121 Joey Lee 2022-07-07 04:17:58 UTC
Thanks for Marcus's help!

(In reply to Marcus Meissner from comment #120)
> SLE one is in 
> SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update

Hi Johannes

Sorry for bother you! Could you please help to send the following SLE/openSUSE shim to Microsoft for signing? 

SLE version:

https://build.suse.de/package/show/SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update

openSUSE Tumbleweed version:

https://build.opensuse.org/request/show/985419

Thanks a lot!
Comment 122 Johannes Segitz 2022-07-07 11:21:18 UTC
yes I'll start with this tomorrow. I was out sick beginning of this week :(
Comment 123 Johannes Segitz 2022-07-11 14:53:47 UTC
They have new questions:
1, ### Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim.

Do we have this list somewhere or do I need to compile it myself?
Comment 124 Marcus Meissner 2022-07-11 15:54:28 UTC
i collected:

fwupdate:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupdate,1,Firmware Update Utility,fwupdate,12,https://github.com/rhboot/fwupdate
fwupdate.sle,1,SUSE Linux Enterprise,fwupdate,12,mail:security-team@suse.de

grub2:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,2,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/
grub.sle,1,SUSE Linux Enterprise,grub2,2.04,mailto:security@suse.de

fwupd:
sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd,1,Firmware update daemon,fwupd,1.5.8,https://github.com/fwupd/fwupd
fwupd-sle,1,SUSE Linux Enterprise,fwupd,1.5.8,https://build.opensuse.org


xen:
no sbat

kernel:
no sbat
Comment 125 Marcus Meissner 2022-07-11 15:57:31 UTC
oh and shim itself:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,2,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.sle,1,SUSE Linux Enterprise,shim,15.6,mail:security-team@suse.de
Comment 126 Marcus Meissner 2022-07-11 16:02:01 UTC
openSUSE:

fwupd:
sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd-efi,1,Firmware update daemon,fwupd-efi,1.2,https://github.com/fwupd/fwupd-efi
fwupd-efi.opensuse,1,The openSUSE Project,fwupd-efi,1.2,mailto:security@suse.de

grub2:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,2,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.opensuse,1,The openSUSE Project,grub2,2.06,mailto:security@suse.de

... and some more for tomorrow
Comment 127 Johannes Segitz 2022-07-12 06:23:49 UTC
thank you Marcus
Comment 128 Johannes Segitz 2022-07-12 12:22:07 UTC
SLES shim review: https://github.com/rhboot/shim-review/issues/263
Comment 129 Johannes Segitz 2022-07-12 12:30:56 UTC
(In reply to Joey Lee from comment #119)
we previously used shim that build against Leap for openSUSE as the Factory environment is to unstable. Can you please prepare a build for Leap 15.4?
Comment 130 Johannes Segitz 2022-07-13 07:26:35 UTC
ATM I get different binaries when building for Leap 15.4 on OBS and rebuilding the sources with the 15.4 images. Judging from the differences this is some binutils change. I can't submit until this is fixed
Comment 131 Joey Lee 2022-07-13 13:43:28 UTC
(In reply to Johannes Segitz from comment #129)
> (In reply to Joey Lee from comment #119)
> we previously used shim that build against Leap for openSUSE as the Factory
> environment is to unstable. Can you please prepare a build for Leap 15.4?

Does Leap 15.4 use the same shim with SLE15-SP3/SLE15-SP4 after closing-gap project? I mean that the shim of Leap 15.4 direct copy from SLE15 SP4?

I have checked the boox64.efi in openSUSE-Leap-15.4-NET-x86_64-Build243.2-Media.iso. The shim be signed by SLE signkey:

linux-691t:/mnt/iso/EFI/BOOT # pesign -S -i bootx64.efi 
---------------------------------------------
certificate address is 0x7f08338af9c0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
certificate address is 0x7f08338b1b20
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is SUSE Linux Enterprise Secure Boot Signkey
The signer's email address is build@suse.de
Signing time: Fri Jul 16, 2021
There were certs or crls included.
---------------------------------------------
Comment 132 Marcus Meissner 2022-07-13 13:50:31 UTC
Johannes wrote he is building the openSUSE shim on Leap to have a stable environment, even if it is used only for Tumbleweed.

can you get the binutils and gcc7 package versions?
Comment 133 Joey Lee 2022-07-13 14:04:37 UTC
(In reply to Johannes Segitz from comment #130)
> ATM I get different binaries when building for Leap 15.4 on OBS and
> rebuilding the sources with the 15.4 images. Judging from the differences
> this is some binutils change. I can't submit until this is fixed

The openSUSE:Leap:15.4:Update/binutils includs the patches for supporting aarch64 in objcopy. It's sync with 15-SP4:

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.4:Update/binutils/binutils.changes?expand=1

-------------------------------------------------------------------
Mon Jun 13 12:09:35 UTC 2022 - Michael Matz <matz@suse.com>

- For building shim 15.6~rc1 (and later versions) aarch64 image, objcopy
  needs to support efi-app-aarch64 target. (bsc#1198458)
  Adds binutils-add-efi-aarch64-1.diff,
  binutils-add-efi-aarch64-2.diff, binutils-add-efi-aarch64-3.diff .

On 15-SP4:
https://build.suse.de/package/view_file/SUSE:SLE-15-SP1:Update/binutils/binutils.changes?expand=1
Comment 134 Joey Lee 2022-07-13 14:09:02 UTC
(In reply to Marcus Meissner from comment #132)
> Johannes wrote he is building the openSUSE shim on Leap to have a stable
> environment, even if it is used only for Tumbleweed.
> 
> can you get the binutils and gcc7 package versions?

I will branch openSUSE:Leap:15.4:Update/shim and move my change from openSUSE:Factory/shim on it.

I hope that it works.
Comment 135 Joey Lee 2022-07-13 14:23:49 UTC
(In reply to Joey Lee from comment #134)
> (In reply to Marcus Meissner from comment #132)
> > Johannes wrote he is building the openSUSE shim on Leap to have a stable
> > environment, even if it is used only for Tumbleweed.
> > 
> > can you get the binutils and gcc7 package versions?
> 
> I will branch openSUSE:Leap:15.4:Update/shim and move my change from
> openSUSE:Factory/shim on it.
> 
> I hope that it works.

I got a problem. I have branched the openSUSE:Leap:15.4:Update/shim, then it is branch from SUSE:SLE-15-SP3:Update/shim on OBS. The patch and spec file is fully the same with 15-SP3 shim. 

But openSUSE TW shim need a specific patch for TW:

# PATCH-FIX-OPENSUSE shim-bsc1198101-opensuse-cert-prompt.patch glin@suse.com -- Show the prompt to ask whether the user trusts openSUSE certificate or not
Patch100:     shim-bsc1198101-opensuse-cert-prompt.patch

This patch doesn't need by 15-SP3/15-SP4. If I apply this patch to 15-SP3/shim on OBS, then the code and spec file will different with the shim of 15-SP3/SP4.


Hi Marcus, Johannes,

Do you know any approach against this situation? Can we have a different code in the SLE-15-SP3:Update/shim between IBS with OBS?

Thanks!
Comment 136 Marcus Meissner 2022-07-13 14:36:11 UTC
You need to branch the tumbleweed shim and configure the project to build against leap instead of tumbleweed. 

So not just a simple branch, but branch and add a new build repository pointing to openSUSE_Tumbleweed
Comment 137 Joey Lee 2022-07-13 15:17:39 UTC
(In reply to Marcus Meissner from comment #136)
> You need to branch the tumbleweed shim and configure the project to build
> against leap instead of tumbleweed. 
> 
> So not just a simple branch, but branch and add a new build repository
> pointing to openSUSE_Tumbleweed

Thanks! I just branched openSUSE:Factory/shim to my home and add a Leap 15.4 repo:

https://build.opensuse.org/project/monitor/home:joeyli:branches:devel:openSUSE:Factory

On the other hand, I forgot to apply Ludwig's SABT change in spec file:

https://build.opensuse.org/request/show/971203

I will also apply it to factory.
Comment 138 Joey Lee 2022-07-15 06:07:21 UTC
(In reply to Joey Lee from comment #137)
> (In reply to Marcus Meissner from comment #136)
> > You need to branch the tumbleweed shim and configure the project to build
> > against leap instead of tumbleweed. 
> > 
> > So not just a simple branch, but branch and add a new build repository
> > pointing to openSUSE_Tumbleweed
> 
> Thanks! I just branched openSUSE:Factory/shim to my home and add a Leap 15.4
> repo:
> 
> https://build.opensuse.org/project/monitor/home:joeyli:branches:devel:
> openSUSE:Factory
> 
> On the other hand, I forgot to apply Ludwig's SABT change in spec file:
> 
> https://build.opensuse.org/request/show/971203
> 
> I will also apply it to factory.

I need to apply patch to rpm-config-SUSE for Leap 15.4, but the patch is copy from SLE15-SP4 because closing gap. 

On the other hand, my idea is that compiler openSUSE:Factory shim on Leap 15.4 base, then submit to Leap 15.4 as a shim-leap package.
Comment 139 Johannes Segitz 2022-07-15 06:46:15 UTC
Sorry for causing confusion here. I didn't know that with closing the leap gap we take the SLES shim for Leap. If this indeed used only for Tumbleweed then we could also compile it for Tumbleweed. The problem with that is that it's likely that shim will not build exactly once we get the signature back due to other changed in Factory. 

With the old setup this happened a lot less as Leap didn't change that much. Unsure what the better option is here. 

Also ATM I still get different binaries in the container and from the build service also for Tumbleweed
Comment 140 Joey Lee 2022-07-15 07:22:41 UTC
(In reply to Johannes Segitz from comment #139)
> Sorry for causing confusion here. I didn't know that with closing the leap
> gap we take the SLES shim for Leap. If this indeed used only for Tumbleweed
> then we could also compile it for Tumbleweed. The problem with that is that
> it's likely that shim will not build exactly once we get the signature back
> due to other changed in Factory. 
> 
> With the old setup this happened a lot less as Leap didn't change that much.
> Unsure what the better option is here. 
> 
> Also ATM I still get different binaries in the container and from the build
> service also for Tumbleweed

It makes sense for building shim on Leap for openSUSE TW because Factory is not stable. 

I have checked that we done the same thing on Leap 15.2 for TW in last time. The difference is that the closing-SLE/openSUSE-gap project be applied since Leap 15.3. So I can not direct apply Ludwig's SBAT change on Leap 15.4.

I have discussed with Max Lin, our release expert. I will do the following steps:

- Send Ludwig's SBAT change in rpm-config-SUSE to SLE15-SP4:Update repo on IBS.
    - After the change be accepted, it should be sync to OBS for Leap 15.4

- Then I will branch shim from Factory, add Leap 15.4 repo to my branch. The factory will be build with new rpm-config-SUSE. (and also with Tumbleweed specific shim patche).

- Then I will submit the new shim in my home branch to Leap-15.4:Update repo. The name will be rename to shim-leap in Leap-15.4:Update.

- Then we can send the shim-leap in Leap-15.4:Update to Microsoft signing. After it back, I will repackage it to Factory.

Thanks!
Comment 141 Johannes Segitz 2022-07-18 07:08:32 UTC
sounds like a plan, thanks. Please needinfo me here once you have it ready to go
Comment 142 Johannes Segitz 2022-07-20 09:10:06 UTC
Any ETA on this? I really want to get this done before my vacation (August). Thanks
Comment 143 Marcus Meissner 2022-07-20 09:13:40 UTC
rpm-config-SUSE is in QA .. top of queue :(
Comment 144 Marcus Meissner 2022-07-20 09:14:00 UTC
but you can have a local copy of it in your shim build branch to shortcut it
Comment 145 Johannes Segitz 2022-07-21 06:08:27 UTC
given how brittle all of this is I would really like to avoid that. Having an "official" binary to compare this too is mandatory IMHO. Then I'll wait
Comment 146 Marcus Meissner 2022-07-21 16:28:33 UTC
rpm-config-SUSE is now released
Comment 147 Joey Lee 2022-07-25 07:52:57 UTC
(In reply to Marcus Meissner from comment #146)
> rpm-config-SUSE is now released

I am working on branch Factory/shim to my branch and add 15.4 repo. I will check the SBAT string. I will send to 15.4/shim-leap if it OK.
Comment 148 Joey Lee 2022-07-25 10:42:30 UTC
(In reply to Joey Lee from comment #147)
> (In reply to Marcus Meissner from comment #146)
> > rpm-config-SUSE is now released
> 
> I am working on branch Factory/shim to my branch and add 15.4 repo. I will
> check the SBAT string. I will send to 15.4/shim-leap if it OK.

Bad~ I have branched Factory:shim to my home. It indeed used the rpm-config-suse from 15-SP4. But shim generated SBAT that it's not for openSUSE

https://build.opensuse.org/package/show/home:joeyli:branches:openSUSE:Leap:15.4:Update/shim



joeyli@linux-l9pv:~/下載/shim-15.6-lp154.3.2> objdump -j .sbat -s ./usr/lib64/efi/shim.efi

The result of .sbat section is:

Contents of section .sbat:
 d1000 73626174 2c312c53 42415420 56657273  sbat,1,SBAT Vers
 d1010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 d1020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 d1030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 d1040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 d1050 2c322c55 45464920 7368696d 2c736869  ,2,UEFI shim,shi
 d1060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 d1070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 d1080 696d0a73 68696d2e 736c652c 312c5355  im.shim.sle,1,SU
 d1090 5345204c 696e7578 20456e74 65727072  SE Linux Enterpr
 d10a0 6973652c 7368696d 2c31352e 362c6d61  ise,shim,15.6,ma
 d10b0 696c746f 3a736563 75726974 79407375  ilto:security@su
 d10c0 73652e64 650a                        se.de.

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md.
shim,2,UEFI shim,shim,1,https://github.com/rhboot/shim.shim.
sle,1,SUSE Linux Enterprise,shim,15.6,mailto:security@suse.de. 

This is because rpm-config-suse is also a closing-gap package. So it direct copy from SLE15-SP4. 

I need to discuss with Ludwig. Maybe I will revoke the change in shim.spec first.
Comment 149 Marcus Meissner 2022-07-25 11:10:28 UTC
"closing-gap" => "closing the leap gap"

Yes, it is a SLE imported package. 

Probably best is really to do the SBAT settings still in the shim.spec
Comment 150 Olaf Hering 2022-07-25 16:59:05 UTC
It seems new shim needs new mokutil:

Tumbleweed  20220715-0 -> 20220719-0  aarch64
warning: %post(shim-15.6-2.1.aarch64) scriptlet failed, exit status 255
mokutil: unrecognized option '--set-sbat-policy'

mokutil was not in the list of packages to update.
Comment 151 Joey Lee 2022-07-26 03:20:28 UTC
(In reply to Olaf Hering from comment #150)
> It seems new shim needs new mokutil:
> 
> Tumbleweed  20220715-0 -> 20220719-0  aarch64
> warning: %post(shim-15.6-2.1.aarch64) scriptlet failed, exit status 255
> mokutil: unrecognized option '--set-sbat-policy'
> 
> mokutil was not in the list of packages to update.

Thanks for Olaf's reminder. I have sent out submit request to Factory for updating mokutil to 0.6.0 version:

https://build.opensuse.org/request/show/991168
Comment 152 Joey Lee 2022-07-26 04:26:12 UTC
(In reply to Marcus Meissner from comment #149)
> "closing-gap" => "closing the leap gap"
> 
> Yes, it is a SLE imported package. 
> 
> Probably best is really to do the SBAT settings still in the shim.spec

Thanks!

And, I have sent request to revoke the change in shim.spec for SBAT section. It will rollback to old approach:

https://build.opensuse.org/request/show/991172

After the change be rollback, I will branch to my home and submit shim-leap to Leap 15.4 repo.
Comment 153 Joey Lee 2022-07-26 10:27:44 UTC
Hi Marcus, 

In the shim 15.6 update for SLE, it still used the mail:security-team@suse.de in SBAT:

https://build.suse.de/package/show/SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update

Do you know how to fix it in the SUSE:Maintenance:24847 ?

Thanks!
Comment 154 Marcus Meissner 2022-07-27 06:12:08 UTC
I would leave it as-is for now, as both security and security-team  email addresses work.
Comment 155 Joey Lee 2022-07-27 09:44:07 UTC
(In reply to Marcus Meissner from comment #154)
> I would leave it as-is for now, as both security and security-team  email
> addresses work.

Thanks for Marcus's suggestion.

We are working on creating a devel project for building shim-leap for Tumbleweed.
I will put information here when it's available.
Comment 158 Joey Lee 2022-07-29 05:44:30 UTC
Unfortunately creating a devel:openSUSE:Factory:shim-leap project doesn't work because it will use devel:opensuse:factory key for signing, not openSUSE key:

joeyli@linux-691t:~/tmp/shim-15.6-4.1> pesign -S -i ./usr/share/efi/x86_64/shim.efi
---------------------------------------------
certificate address is 0x7f1bb8296f88
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is devel:openSUSE:Factory OBS Project
The signer's email address is devel:opensuse:factory@build.opensuse.org
Signing time: Fri Jul 29, 2022
There were certs or crls included.
---------------------------------------------

The signature in current openSUSE:Factory/shim is:

joeyli@linux-691t:~/tmp/shim-15.4-4.5> pesign -S -i ./usr/share/efi/x86_64/shim.efi
---------------------------------------------
certificate address is 0x7ff4f91087c0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
certificate address is 0x7ff4f910a920
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is openSUSE Secure Boot Signkey
The signer's email address is build@opensuse.org
Signing time: Thu Jul 15, 2021
There were certs or crls included.
---------------------------------------------

Before we send the shim.efi for Microsoft signing, we need to make sure the the shim.efi be signed by openSUSE Secure Boot Signkey first.
Comment 159 Joey Lee 2022-07-29 06:04:45 UTC
Our requirements of the space for building shim of Tumbleweed are:

- The shim.efi can not duplicated.
    - The shim-leap can only be used to produce a shim.rpm.

- The shim.efi must be signed by "openSUSE Secure Boot Signkey".

- The shim.efi embeds openSUSE SBAT, not SLE SBAT.

In last time shim release, we borrowed openSUSE:Leap:15.2:Update to build the shim for Tumbleweed. The old procedure is:

- Push new shim to openSUSE:Leap:15.2:Update/shim for building.
    - This shim will be signed by "openSUSE Secure Boot Signkey".

- Johannes takes the shim.efi from openSUSE:Leap:15.2:Update/shim and send to Microsoft signing.

- After Microsoft signed back, Johannes replaces the signed shim.efi to openSUSE:Leap:15.2:Update/shim.

- Joey Lee takes the shim.rpm from openSUSE:Leap:15.2:Update/shim repo and repackage it to openSUSE:Factory/shim-leap.

- The openSUSE:Factory/shim-leap produces a shim-xxx.rpm. It will be used in Tumbleweed iso.


In the above procedure, the openSUSE:Leap:15.2:Update is old and end of life. We should find another stable repo to do the job. openSUSE:Leap:15.4 is stable but it uses the shim from SLE15-SP4 because closing-the-leap-gap. So the only solution is that we create a subproject under openSUSE:Leap:15.4 or openSUSE:Leap:15.4:Update. 

For example: openSUSE:Leap:15.4:shim-leap subproject
Comment 160 Johannes Segitz 2022-07-29 13:36:07 UTC
I'll be away on vacation after today. I handed the signing dongle and laptop to Robert, who I also CC here. The openSUSE submission is mostly prepared and "just" needs the proper sources to build the container that replicates the build
Comment 161 Swamp Workflow Management 2022-08-03 13:17:47 UTC
SUSE-SU-2022:2637-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server 12-SP5 (src):    mokutil-0.2.0-23.6.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 162 Swamp Workflow Management 2022-08-03 13:19:01 UTC
SUSE-SU-2022:2635-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server for SAP 15 (src):    mokutil-0.3.0-150000.4.3.1
SUSE Linux Enterprise High Performance Computing 15-LTSS (src):    mokutil-0.3.0-150000.4.3.1
SUSE Linux Enterprise High Performance Computing 15-ESPOS (src):    mokutil-0.3.0-150000.4.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 163 Swamp Workflow Management 2022-08-03 13:19:37 UTC
SUSE-SU-2022:2636-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server for SAP 15-SP1 (src):    mokutil-0.3.0-150100.8.9.1
SUSE Linux Enterprise Server 15-SP1-LTSS (src):    mokutil-0.3.0-150100.8.9.1
SUSE Linux Enterprise Server 15-SP1-BCL (src):    mokutil-0.3.0-150100.8.9.1
SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src):    mokutil-0.3.0-150100.8.9.1
SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src):    mokutil-0.3.0-150100.8.9.1
SUSE Enterprise Storage 6 (src):    mokutil-0.3.0-150100.8.9.1
SUSE CaaS Platform 4.0 (src):    mokutil-0.3.0-150100.8.9.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 164 Swamp Workflow Management 2022-08-03 13:20:11 UTC
SUSE-SU-2022:2633-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.4 (src):    mokutil-0.5.0-150400.3.3.1
SUSE Linux Enterprise Module for Basesystem 15-SP4 (src):    mokutil-0.5.0-150400.3.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 165 Swamp Workflow Management 2022-08-03 13:20:52 UTC
SUSE-SU-2022:2638-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Manager Server 4.1 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Manager Retail Branch Server 4.1 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Manager Proxy 4.1 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Server for SAP 15-SP2 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Server 15-SP2-LTSS (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Server 15-SP2-BCL (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Micro 5.2 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise Micro 5.1 (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise High Performance Computing 15-SP2-LTSS (src):    mokutil-0.4.0-150200.4.6.1
SUSE Linux Enterprise High Performance Computing 15-SP2-ESPOS (src):    mokutil-0.4.0-150200.4.6.1
SUSE Enterprise Storage 7 (src):    mokutil-0.4.0-150200.4.6.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 166 Joey Lee 2022-08-03 15:10:18 UTC
Hi Johannes, 

Dominique helped us to create a openSUSE:Factory:secure-boot project for building
the shim of Tumbleweed. The shim be signed by openSUSE signkey. Could you please help
to send the following SLE/openSUSE shim for Microsoft signing?

SLE version:

https://build.suse.de/package/show/SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update

openSUSE Tumbleweed version:

https://build.opensuse.org/package/binaries/openSUSE:Factory:secure-boot/shim/15.4

Thanks a lot!
Comment 168 Swamp Workflow Management 2022-08-09 16:35:09 UTC
SUSE-SU-2022:2716-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1198458
CVE References: 
JIRA References: 
Sources used:
SUSE OpenStack Cloud Crowbar 9 (src):    mokutil-0.2.0-12.3.1
SUSE OpenStack Cloud 9 (src):    mokutil-0.2.0-12.3.1
SUSE Linux Enterprise Server for SAP 12-SP4 (src):    mokutil-0.2.0-12.3.1
SUSE Linux Enterprise Server 12-SP4-LTSS (src):    mokutil-0.2.0-12.3.1
SUSE Linux Enterprise Server 12-SP3-BCL (src):    mokutil-0.2.0-12.3.1
SUSE Linux Enterprise Server 12-SP2-BCL (src):    mokutil-0.2.0-12.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.