|
Bugzilla – Full Text Bug Listing |
| Summary: | MokManager trouble when upgrading from non-SB enabled system (15.0 aarch64) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Fabian Vogt <fvogt> |
| Component: | Installation | Assignee: | YaST Team <yast-internal> |
| Status: | CONFIRMED --- | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Minor | ||
| Priority: | P5 - None | CC: | dgonzalez, fvogt, guillaume.gardet, jlee, jreidinger, mchang, rw, yast2-maintainers |
| Version: | Leap 15.4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://openqa.opensuse.org/tests/2077067/modules/grub_test/steps/4 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Fabian Vogt
2021-12-13 15:18:06 UTC
It seems to be offline migration via installation media that YaST would re-proposed or re-initialized settings from scratch for some reason. Maybe we should check with YaST team first if they know secure boot settings would be altered in the migration process ? @ Hi YaST Team, Would you please help to check that secure boot setting could be altered during offline migration ? For the second question. To my understanding, openQA testcase has been conducted to use "Boot from Hard Disk" from the media to booting into upgraded system for a long time. I have raised the question in other bug report why it couldn't just reboot into upgraded system but it seems there are some difficulties to do so. I think grub-install or shim-install has made their boot order higher than cdrom device, but given that only cdrom has bootindex=0 attached, the firmware would not enumerate other device without bootindex if booting unattended. For this reason I don't think hard system reset would work to boot into updated system and instead would be trapped in cdrom over again ... jreidinger should know. Josef? (In reply to Michael Chang from comment #1) > It seems to be offline migration via installation media that YaST would > re-proposed or re-initialized settings from scratch for some reason. Maybe > we should check with YaST team first if they know secure boot settings would > be altered in the migration process ? > > @ Hi YaST Team, > > Would you please help to check that secure boot setting could be altered > during offline migration ? It's actually visible in the openQA test as well that YaST saves the wrong setting: https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/12 shows "Secure boot: disabled" https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/16 shows the checkbox for Secure boot remains unchecked https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/21 shows that the This is using the regular DVD upgrade, which behaves the same way as the live upgrade linked in the initial report. Reassigning to the YaST team and raising severity. > For the second question. To my understanding, openQA testcase has been > conducted to use "Boot from Hard Disk" from the media to booting into > upgraded system for a long time. I have raised the question in other bug > report why it couldn't just reboot into upgraded system but it seems there > are some difficulties to do so. > > I think grub-install or shim-install has made their boot order higher than > cdrom device, but given that only cdrom has bootindex=0 attached, the > firmware would not enumerate other device without bootindex if booting > unattended. For this reason I don't think hard system reset would work to > boot into updated system and instead would be trapped in cdrom over again ... Yep, and if the HDD had a bootindex with higher priority, the upgrade couldn't be started at all... There doesn't seem to be a "once" option with bootindex like for "-boot". One question remains. does shim really have to force-reset the platform if MokManager was not found? It could just print a warning and continue, which would be much more user friendly. (In reply to Fabian Vogt from comment #3) > (In reply to Michael Chang from comment #1) > > It seems to be offline migration via installation media that YaST would > > re-proposed or re-initialized settings from scratch for some reason. Maybe > > we should check with YaST team first if they know secure boot settings would > > be altered in the migration process ? > > > > @ Hi YaST Team, > > > > Would you please help to check that secure boot setting could be altered > > during offline migration ? > > It's actually visible in the openQA test as well that YaST saves the wrong > setting: > > https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/12 shows > "Secure boot: disabled" > https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/16 shows > the checkbox for Secure boot remains unchecked > https://openqa.opensuse.org/tests/2076948#step/disable_grub_timeout/21 shows > that the ... overview suddenly has "Secure boot: enabled" set, after leaving the bootloader module. yeap, that looks wrong to have it set to enabled, especially when checkbox is disabled. Sadly the debug logs from openqa already rolled away from proposal, so I do not see in logs why it happens. We need to reproduce it and check why. and few more questions: 1. is it seen only on arch and nothing else? 2. Does it happen only on liveDVD or do you see it also using non live medium? (In reply to Fabian Vogt from comment #3) > (In reply to Michael Chang from comment #1) [snip] > Yep, and if the HDD had a bootindex with higher priority, the upgrade > couldn't be started at all... There doesn't seem to be a "once" option with > bootindex like for "-boot". I'm curious why -boot once=d cannot be used here and why this is not observed behavior in regular install other than in the openQA. > One question remains. does shim really have to force-reset the platform if > MokManager was not found? It could just print a warning and continue, which > would be much more user friendly. I agree with you that normally it could just print warning and continue to next boot order as this is what most people expect it to happen after synchronous boot errors in general. However this is shim under many security reviews by Microsoft and other linux distributions so any proposed change to error handling, security violation in particular, is required to have it upstream first imho (whenever worth it). RT->ResetSystem(EfiResetShutdown, EFI_SECURITY_VIOLATION, We can argue that missing mokmanager is not an security violation in secure boot or it should not reset system in reaction to that. I'm not security expert eligible to make such adjustment, security implication is all around for those who audits security in the code. CC Joey who is currently in charge of shim. (In reply to Josef Reidinger from comment #6) > and few more questions: > > 1. is it seen only on arch and nothing else? In x86 tests, secure boot is on by default (in the system, not necessarily the test VM), so this bug wouldn't be visible in openQA. On other platforms there's no secure boot option. > 2. Does it happen only on liveDVD or do you see it also using non live > medium? Comment 3 has links to a plain DVD upgrade test where this happens. (In reply to Fabian Vogt from comment #8) > (In reply to Josef Reidinger from comment #6) > > and few more questions: > > > > 1. is it seen only on arch and nothing else? > > In x86 tests, secure boot is on by default (in the system, not necessarily > the test VM), so this bug wouldn't be visible in openQA. On other platforms > there's no secure boot option. > > > 2. Does it happen only on liveDVD or do you see it also using non live > > medium? > > Comment 3 has links to a plain DVD upgrade test where this happens. Thanks, so I think it is related to fact that we do not support secure boot for arm for 15.0 at all. Then we have specific grub parameter and I think now we support shim. I remember that we already had in past some issues with it like change or software dependencies to install bootloader. What is for sure bug is showing secure boot as not enabled and then enable it. I worry it is different interpretation of missing parameter in /etc/sysconfig/bootloader and that should be fixed ( not sure if we should always enable secure boot if previously it was not supported ). Moved to our Trello task queue for a future sprint. |