|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 154.1] secure boot is enabled on aarch64 by installer even when disabled on test machine | ||
|---|---|---|---|
| Product: | [SUSE Linux Enterprise Server] PUBLIC SUSE Linux Enterprise Server 15 SP3 | Reporter: | Alvaro Carvajal <acarvajal> |
| Component: | Installer | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P1 - Urgent | CC: | afaerber, chester.lin, fcrozat, glin, jlee, jreidinger, llzhao, ptesarik, riafarov, richard.fan |
| Version: | Public Beta | ||
| Target Milestone: | unspecified | ||
| Hardware: | aarch64 | ||
| OS: | SLES 15 | ||
| URL: | https://trello.com/c/GSWoJy3g | ||
| See Also: |
https://bugzilla.suse.com/show_bug.cgi?id=1182640 https://bugzilla.suse.com/show_bug.cgi?id=1174111 |
||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
YaST logs
Serial Console |
||
|
Description
Alvaro Carvajal
2021-02-25 12:58:17 UTC
Created attachment 846514 [details]
YaST logs
Created attachment 846515 [details]
Serial Console
Well, reason is simple. When we start with secure boot on x86_64 answer when to propose it is that we should propose it by default always as it is safe option and shim can handle it. And it is same for other architectures with EFI and only exception is s390 secure boot where it is checked if it is available at all https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/systeminfo.rb#L105 Andreas, it seems we are a bit stuck here. According to our knowledge, this is expected behavior, but it does not seem to work. We can'd decide what should happen now. Maybe asking shim maintainer? Please, decide. (In reply to Lukas Ocilka from comment #5) > Andreas, it seems we are a bit stuck here. According to our knowledge, this > is expected behavior, but it does not seem to work. We can'd decide what > should happen now. Maybe asking shim maintainer? Please, decide. Shim experts are already in CC. Bug #1182640 (an extension of bug #1182210) simply needs to be fixed by making mokutil available on aarch64 (000package-groups). That'll solve the dependency. I don't see another issue here right now - although we should keep an eye out for any Tumbleweed-style issues with systems that don't have read/writeable efivarfs. If our shim gets installed as bootaa64.efi then I would expect (subject to tests) that all systems should be able to boot it, also without Secure Boot enabled and also with read-only or no UEFI variables. If that assumption holds true, that leaves us with GRUB, mokutil, efibootmgr and related tools potentially being unable to add/modify UEFI variables for boot entries and their callers needing to handle that gracefully one way or another. If we're unable/unwilling to handle it that way, we may need to detect read-only UEFI variables (or lack of UEFI variables, thinking of Automotive or recovery) and disable the Secure Boot default at runtime accordingly. (In reply to Andreas Färber from comment #6) > (In reply to Lukas Ocilka from comment #5) > > Andreas, it seems we are a bit stuck here. According to our knowledge, this > > is expected behavior, but it does not seem to work. We can'd decide what > > should happen now. Maybe asking shim maintainer? Please, decide. > > Shim experts are already in CC. > > Bug #1182640 (an extension of bug #1182210) simply needs to be fixed by > making mokutil available on aarch64 (000package-groups). That'll solve the > dependency. > > I don't see another issue here right now - although we should keep an eye > out for any Tumbleweed-style issues with systems that don't have > read/writeable efivarfs. > > If our shim gets installed as bootaa64.efi then I would expect (subject to > tests) that all systems should be able to boot it, also without Secure Boot > enabled and also with read-only or no UEFI variables. > If that assumption holds true, that leaves us with GRUB, mokutil, efibootmgr > and related tools potentially being unable to add/modify UEFI variables for > boot entries and their callers needing to handle that gracefully one way or > another. > > If we're unable/unwilling to handle it that way, we may need to detect > read-only UEFI variables (or lack of UEFI variables, thinking of Automotive > or recovery) and disable the Secure Boot default at runtime accordingly. Well, in installer we have that no_nvram and also removable if we detect something like ro EFI and we apply it also when calling shim https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/grub_install.rb#L102 I am not sure if it is enough? In fact for aarch64 we run always removable and when we found efivars we run also without removable https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/grub_install.rb#L102 so booting on aarch is currently probably the most complex one in installer :) Hi Josef, (In reply to Josef Reidinger from comment #9) > (In reply to Andreas Färber from comment #6) > > (In reply to Lukas Ocilka from comment #5) > > > Andreas, it seems we are a bit stuck here. According to our knowledge, this > > > is expected behavior, but it does not seem to work. We can'd decide what > > > should happen now. Maybe asking shim maintainer? Please, decide. > > > > Shim experts are already in CC. > > > > Bug #1182640 (an extension of bug #1182210) simply needs to be fixed by > > making mokutil available on aarch64 (000package-groups). That'll solve the > > dependency. > > > > I don't see another issue here right now - although we should keep an eye > > out for any Tumbleweed-style issues with systems that don't have > > read/writeable efivarfs. > > > > If our shim gets installed as bootaa64.efi then I would expect (subject to > > tests) that all systems should be able to boot it, also without Secure Boot > > enabled and also with read-only or no UEFI variables. > > If that assumption holds true, that leaves us with GRUB, mokutil, efibootmgr > > and related tools potentially being unable to add/modify UEFI variables for > > boot entries and their callers needing to handle that gracefully one way or > > another. > > > > If we're unable/unwilling to handle it that way, we may need to detect > > read-only UEFI variables (or lack of UEFI variables, thinking of Automotive > > or recovery) and disable the Secure Boot default at runtime accordingly. > > Well, in installer we have that no_nvram and also removable if we detect > something like ro EFI and we apply it also when calling shim > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > grub_install.rb#L102 > I am not sure if it is enough? In fact for aarch64 we run always removable > and when we found efivars we run also without removable > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > grub_install.rb#L102 > so booting on aarch is currently probably the most complex one in installer > :) Could you please also add the detection of the Read_Only attribute on efivarfs? Kernel will mount efivarfs with RO when firmware doesn't support SetVariable EFI protocol, which means the EFI variables can only be read, so boot entry can not be created success. e.g. For detection, Using mount command or cat /proc/mounts linux-npj3:~ # mount | grep efivarfs efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime) linux-npj3:~ # cat /proc/mounts | grep efivarfs efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0 Please also reference comment#37-39 on bsc#1174111. Thanks a lot! (In reply to Joey Lee from comment #10) > Hi Josef, > > (In reply to Josef Reidinger from comment #9) > > (In reply to Andreas Färber from comment #6) > > > (In reply to Lukas Ocilka from comment #5) > > > > Andreas, it seems we are a bit stuck here. According to our knowledge, this > > > > is expected behavior, but it does not seem to work. We can'd decide what > > > > should happen now. Maybe asking shim maintainer? Please, decide. > > > > > > Shim experts are already in CC. > > > > > > Bug #1182640 (an extension of bug #1182210) simply needs to be fixed by > > > making mokutil available on aarch64 (000package-groups). That'll solve the > > > dependency. > > > > > > I don't see another issue here right now - although we should keep an eye > > > out for any Tumbleweed-style issues with systems that don't have > > > read/writeable efivarfs. > > > > > > If our shim gets installed as bootaa64.efi then I would expect (subject to > > > tests) that all systems should be able to boot it, also without Secure Boot > > > enabled and also with read-only or no UEFI variables. > > > If that assumption holds true, that leaves us with GRUB, mokutil, efibootmgr > > > and related tools potentially being unable to add/modify UEFI variables for > > > boot entries and their callers needing to handle that gracefully one way or > > > another. > > > > > > If we're unable/unwilling to handle it that way, we may need to detect > > > read-only UEFI variables (or lack of UEFI variables, thinking of Automotive > > > or recovery) and disable the Secure Boot default at runtime accordingly. > > > > Well, in installer we have that no_nvram and also removable if we detect > > something like ro EFI and we apply it also when calling shim > > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > > grub_install.rb#L102 > > I am not sure if it is enough? In fact for aarch64 we run always removable > > and when we found efivars we run also without removable > > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > > grub_install.rb#L102 > > so booting on aarch is currently probably the most complex one in installer > > :) > > Could you please also add the detection of the Read_Only attribute on > efivarfs? Kernel will mount efivarfs with RO when firmware doesn't support > SetVariable EFI protocol, which means the EFI variables can only be read, so > boot entry can not be created success. > > e.g. For detection, Using mount command or cat /proc/mounts > > linux-npj3:~ # mount | grep efivarfs > efivarfs on /sys/firmware/efi/efivars type efivarfs > (ro,nosuid,nodev,noexec,relatime) > > linux-npj3:~ # cat /proc/mounts | grep efivarfs > efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime > 0 0 > > Please also reference comment#37-39 on bsc#1174111. > > Thanks a lot! Hi Joey, I can do it, but need more info. At first does it effect all architectures or is it ARM specific? And as ARM booting getting more and more complex, is there some good source of documentation that we can link from our code? As currently we are already referencing bunch of bug reports and features and it is getting more and more hard to keep overall picture. Thanks Josef (In reply to Josef Reidinger from comment #11) > And as ARM booting getting more and more complex, is there some good source > of documentation that we can link from our code? As currently we are already > referencing bunch of bug reports and features and it is getting more and > more hard to keep overall picture. In other words: We'd ideally need some document, description, workflow, diagram, ... how it should ALL work "tomorrow" maybe in if-this-than-that form. Maybe this part even deserves rewriting from scratch, we don't know yet. Hi Josef, (In reply to Josef Reidinger from comment #11) > (In reply to Joey Lee from comment #10) > > Hi Josef, > > > > (In reply to Josef Reidinger from comment #9) > > > (In reply to Andreas Färber from comment #6) > > > > (In reply to Lukas Ocilka from comment #5) > > > > > Andreas, it seems we are a bit stuck here. According to our knowledge, this > > > > > is expected behavior, but it does not seem to work. We can'd decide what > > > > > should happen now. Maybe asking shim maintainer? Please, decide. > > > > > > > > Shim experts are already in CC. > > > > > > > > Bug #1182640 (an extension of bug #1182210) simply needs to be fixed by > > > > making mokutil available on aarch64 (000package-groups). That'll solve the > > > > dependency. > > > > > > > > I don't see another issue here right now - although we should keep an e [...ship] > > > > > > Well, in installer we have that no_nvram and also removable if we detect > > > something like ro EFI and we apply it also when calling shim > > > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > > > grub_install.rb#L102 > > > I am not sure if it is enough? In fact for aarch64 we run always removable > > > and when we found efivars we run also without removable > > > https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ > > > grub_install.rb#L102 > > > so booting on aarch is currently probably the most complex one in installer > > > :) > > > > Could you please also add the detection of the Read_Only attribute on > > efivarfs? Kernel will mount efivarfs with RO when firmware doesn't support > > SetVariable EFI protocol, which means the EFI variables can only be read, so > > boot entry can not be created success. > > > > e.g. For detection, Using mount command or cat /proc/mounts > > > > linux-npj3:~ # mount | grep efivarfs > > efivarfs on /sys/firmware/efi/efivars type efivarfs > > (ro,nosuid,nodev,noexec,relatime) > > > > linux-npj3:~ # cat /proc/mounts | grep efivarfs > > efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime > > 0 0 > > > > Please also reference comment#37-39 on bsc#1174111. > > > > Thanks a lot! > > Hi Joey, > I can do it, but need more info. At first does it effect all architectures > or is it ARM specific? > And as ARM booting getting more and more complex, is there some good source > of documentation that we can link from our code? As currently we are already > referencing bunch of bug reports and features and it is getting more and > more hard to keep overall picture. > It is architecture independent. It is base on EFI_RT_PROPERTIES table which works both with x86_64 and aarch64. Thanks Also see Rodion's comment on bsc#1182776: https://bugzilla.suse.com/show_bug.cgi?id=1182776#c12 The other two aarch64 related bugs blocking installation of aarch64 are meanwhile resolved in build156.3 (bsc#1182640 and bsc#1182663), with this issue still occurring and also bsc#1182776 having an impact on aarch64 and secureboot. fix for read only efivars is in place https://github.com/yast/yast-bootloader/pull/635 SUSE-RU-2021:0968-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1174111,1182749 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): yast2-bootloader-4.2.28-3.9.1 SUSE Linux Enterprise Installer 15-SP2 (src): yast2-bootloader-4.2.28-3.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. openSUSE-RU-2021:0497-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1174111,1182749 CVE References: JIRA References: Sources used: openSUSE Leap 15.2 (src): yast2-bootloader-4.2.28-lp152.2.9.1 SUSE-RU-2023:3149-1: An update that contains four features and has 15 recommended fixes can now be installed. Category: recommended (important) Bug References: 1136601, 1157550, 1167015, 1172293, 1174111, 1174320, 1182749, 1184160, 1188768, 1192764, 1198197, 1198828, 1201399, 1208003, 1210799 Jira References: SLE-11500, SLE-15020, SLE-15823, SLE-18271 Sources used: SUSE OpenStack Cloud 9 (src): perl-Bootloader-0.944-3.3.1 SUSE OpenStack Cloud Crowbar 9 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise Server for SAP Applications 12 SP4 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise Server 12 SP4 ESPOS 12-SP4 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise Server 12 SP4 LTSS 12-SP4 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise High Performance Computing 12 SP5 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise Server 12 SP5 (src): perl-Bootloader-0.944-3.3.1 SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): perl-Bootloader-0.944-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. |