Mirrored MOK variables could be accidentally deleted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
shim |
New
|
Unknown
|
|||
shim (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned | ||
shim-signed (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
On some systems, Mok variables mirrored are accidentally deleted after the mirroring. This can prevent the kernel from loading DKMS modules, if it does not yet use the config table to parse the MokList variable; and userspace tools relying on the variables will have wrong results.
Most implementations reject the accidental delete, as the flags do not match, this bug was produced on VMWare.
[Test plan]
If we can get a VMWare Workstation or Player license, it would be good to validate that. Without a license, the best we can do is ensure there are no regressions on other machines and rely on the authors of the patch (SUSE) to have tested this properly.
[Where problems could occur]
We could accidentally delete the variable on other systems now.
Changed in shim: | |
status: | Unknown → New |
description: | updated |
Changed in shim-signed (Ubuntu): | |
status: | New → Fix Released |
It was my understanding that the kernel only ever supported reading the secure mok variables prior to calling ExitBootServices(), never the mirrored variables, so I don't understand how there could be a bug here.