Bug 1715202
| Summary: | enabling fips mode after kernel update results in inconsistent state | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ondrej Moriš <omoris> |
| Component: | crypto-policies | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | lnykryn, nmavrogi, ssorce |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | Flags: | tmraz:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | crypto-policies-20190613-1.git21ffdc8.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-05 22:33:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ondrej Moriš
2019-05-29 19:33:12 UTC
Lukáš, what do you think? My opinion: The --regenerate-all is too big hammer. I do not think we want to modify initramfs for older kernels. Ideally we should regenerate initramfs for the kernel that will be booted after the reboot (and probably also for the kernel that is currently booted). Lukáš, would it be possible to modify dracut -f without other options to regenerate both these kernels? Or if you think it is not a good idea to change dracut semantics, could you suggest what would be the best way to achieve this by calling dracut? Of course we would want to avoid stuff like always call dracut twice if the kernel that is booted now and that will be booted next is the same kernel as calling dracut is already quite time consuming. How do you modify the grub configuration? I would presume that you set fips=1 for all entries and in such case, I think it also makes sense to regenerate all initramdisks as well, since otherwise you will get the inconsistent state for all the old entries. We use grubby to update the default kernel only but we also use grub2-editenv to modify the grubenv. I actually did not try whether this means it will affect all kernel command lines for old kernels or not. Historically without BLS the grubby call affected only the default kernel (i.e. the one that will be booted next). However it is a good point that with BLS and editing grubenv it might actually affect all kernels. Ondrej, do you have some machine ready where we could easily check whether the grub2-editenv affects all the kernels? (In reply to Tomas Mraz from comment #5) > Ondrej, do you have some machine ready where we could easily check whether > the grub2-editenv affects all the kernels? Sorry, I was on PTO but I will try it right away. OK, the answer is yes - grub2-editenv affects all the kernel. IOW, when I have two kernels installed then kernelopts modifications via grub2-editenv affect all kernels installed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3644 |