Bugzilla – Bug 1198458
VUL-0: CVE-2022-28737: shim: buffer overflow
Last modified: 2023-03-22 04:24:50 UTC
CRD: 2022-04-26 from grub2 predisclosure group currently trying to find the details.
AFAIK the CRD may have been moved to May 17 ?
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?
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
(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.
(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.
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.)
CRD: 2022-05-24
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.
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.
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.
(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.
(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
in which group did you get the sbats ? not sure if i am subscribed there?
(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.
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
(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
(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
(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.
(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
(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
(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
Created attachment 858625 [details] shim: Patches for CVE-2022-28737 Note: The patch is based on rhboot/shim master branch.
(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!
(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
(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
(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
(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?
(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 � � � ���� � � � � � � � � � � � � � � � � � � � � � ������������������������������������������������
(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.
(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?
(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.
(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.
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?
(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
(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.
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.
(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.
Created attachment 858815 [details] grub2.cve_2021_3695.disclosure.txt *Current* draft for disclosure requirement in grub and shim.
(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 ..
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!
(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!
(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!
(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.
(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.
(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.
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
(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
New CRD was set to allow shim code to be ready. CRD: 2022-06-07 10:00PT
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
(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);
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!
(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);
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.
(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.
(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.
(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.
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.
(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.
(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!
(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
(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 ...
(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.
(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'
public npow
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
(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.
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?
(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 .
(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.
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.
The updated binutils be merged. So I have submitreq shim 15.6 to 15-SP3 update repo: https://build.suse.de/request/show/274886
(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
SLE one is in SUSE:Maintenance:24847/shim.SUSE_SLE-15-SP3_Update
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!
yes I'll start with this tomorrow. I was out sick beginning of this week :(
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?
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
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
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
thank you Marcus
SLES shim review: https://github.com/rhboot/shim-review/issues/263
(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?
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
(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. ---------------------------------------------
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?
(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
(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.
(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!
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
(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.
(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.
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
(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!
sounds like a plan, thanks. Please needinfo me here once you have it ready to go
Any ETA on this? I really want to get this done before my vacation (August). Thanks
rpm-config-SUSE is in QA .. top of queue :(
but you can have a local copy of it in your shim build branch to shortcut it
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
rpm-config-SUSE is now released
(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.
(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.
"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
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.
(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
(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.
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!
I would leave it as-is for now, as both security and security-team email addresses work.
(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.
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.
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
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
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.
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.
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.
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.
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.
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!
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.
Gary is not the maintainer of SUSE shim now. Set needinfo to me.
openSUSE review https://github.com/rhboot/shim-review/issues/283 This is so brittle. Lets hope that it's fine
Thanks for your work. I'll start with that Monday
SUSE-SU-2022:4277-1: An update that solves 10 vulnerabilities, contains 10 features and has 5 fixes is now available. Category: security (important) Bug References: 1142579,1185597,1185712,1188374,1191473,1191908,1193929,1194783,1197592,1198237,1198458,1202816,1202966,1202967,1202969 CVE References: CVE-2019-1010204,CVE-2021-3530,CVE-2021-3648,CVE-2021-3826,CVE-2021-45078,CVE-2021-46195,CVE-2022-27943,CVE-2022-38126,CVE-2022-38127,CVE-2022-38533 JIRA References: PED-2029,PED-2030,PED-2031,PED-2032,PED-2033,PED-2034,PED-2035,PED-2038,SLE-25046,SLE-25047 Sources used: SUSE OpenStack Cloud Crowbar 9 (src): binutils-2.39-9.50.1 SUSE OpenStack Cloud 9 (src): binutils-2.39-9.50.1 SUSE Linux Enterprise Software Development Kit 12-SP5 (src): binutils-2.39-9.50.1, cross-ppc-binutils-2.39-9.50.1, cross-spu-binutils-2.39-9.50.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): binutils-2.39-9.50.1 SUSE Linux Enterprise Server 12-SP5 (src): binutils-2.39-9.50.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): binutils-2.39-9.50.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): binutils-2.39-9.50.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): binutils-2.39-9.50.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.
Please submit (also) to SLE15-4. I need to provide a container that build this bit-identical for review, and since there's not 15-5 image available I can't do this. Thank you
Hi (In reply to Johannes Segitz from comment #194) > Please submit (also) to SLE15-4. I need to provide a container that build > this bit-identical for review, and since there's not 15-5 image available I > can't do this. > I just submit 15.7 shim to SLE15-SP4: https://build.suse.de/request/show/285497 Like SEL15-SP4 staging project, the hash checking needs to be disabled. Thanks a lot!
thanks, with that I can build it bit identical. Should be able to submit it tomorrow
SLES shim review request: https://github.com/rhboot/shim-review/issues/301
The reviewer brought up https://github.com/rhboot/shim/issues/533 Can you please check if we're affected and fix it if necessary (lets hope not, I don't want to redo the submissions ...)
(In reply to Johannes Segitz from comment #200) > The reviewer brought up > https://github.com/rhboot/shim/issues/533 > Can you please check if we're affected and fix it if necessary (lets hope > not, I don't want to redo the submissions ...) This new patch only affects an assemble .S file compiled by old binutils(<=v2.35); While our current binutils version is >=v2.37
(In reply to Tseng from comment #201) > (In reply to Johannes Segitz from comment #200) > > The reviewer brought up > > https://github.com/rhboot/shim/issues/533 > > Can you please check if we're affected and fix it if necessary (lets hope > > not, I don't want to redo the submissions ...) > > This new patch only affects an assemble .S file compiled by old > binutils(<=v2.35); While our current binutils version is >=v2.37 We just tried the shim-15.7, and got the result is ok: > objdump -j .sbatlevel -s shim.efi shim.efi 檔案格式 pei-x86-64 .sbatlevel 區段的內容： 84000 00000000 08000000 22000000 73626174 ........"...sbat 84010 2c312c32 30323230 35323430 300a6772 ,1,2022052400.gr 84020 75622c32 0a007362 61742c31 2c323032 ub,2..sbat,1,202 84030 32313131 3530300a 7368696d 2c320a67 2111500.shim,2.g 84040 7275622c 330a00 rub,3..