| 2016-07-20 15:49:06 |
Steve Langasek |
bug |
|
|
added bug |
| 2016-07-20 15:50:00 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Xenial) |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
nominated for series |
|
Ubuntu Precise |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Precise) |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Trusty) |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
nominated for series |
|
Ubuntu Wily |
|
| 2016-07-20 15:50:00 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Wily) |
|
| 2016-07-20 16:44:13 |
Launchpad Janitor |
shim-signed (Ubuntu): status |
New |
Fix Released |
|
| 2016-07-20 19:28:29 |
Steve Langasek |
description |
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
[SRU Justification]
In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system. As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
[Test case]
1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
2. Create the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable with a value of 1 XXX: figure out how to do this
3. Install shim-signed from -updates.
4. Install the dahdi-dkms package.
5. Confirm that you are not prompted to disable secureboot.
6. Install shim-signed from -proposed.
7. Confirm that you *are* prompted to disable secureboot.
8. Delete the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable.
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
|
| 2016-07-20 19:55:20 |
Steve Langasek |
description |
[SRU Justification]
In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system. As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
[Test case]
1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
2. Create the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable with a value of 1 XXX: figure out how to do this
3. Install shim-signed from -updates.
4. Install the dahdi-dkms package.
5. Confirm that you are not prompted to disable secureboot.
6. Install shim-signed from -proposed.
7. Confirm that you *are* prompted to disable secureboot.
8. Delete the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable.
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
[SRU Justification]
In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system. As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
[Test case]
1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
3. Install shim-signed from -updates.
4. Install the dahdi-dkms package.
5. Confirm that you are not prompted to disable secureboot.
6. Install shim-signed from -proposed.
7. Confirm that you *are* prompted to disable secureboot.
8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
|
| 2016-07-20 19:58:05 |
Steve Langasek |
description |
[SRU Justification]
In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system. As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
[Test case]
1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
3. Install shim-signed from -updates.
4. Install the dahdi-dkms package.
5. Confirm that you are not prompted to disable secureboot.
6. Install shim-signed from -proposed.
7. Confirm that you *are* prompted to disable secureboot.
8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
[SRU Justification]
In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system. As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
[Test case]
1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
3. Install shim-signed from -updates.
4. Install the dahdi-dkms package.
5. Confirm that you are not prompted to disable secureboot.
6. Install shim-signed from -proposed.
7. Confirm that you *are* prompted to disable secureboot.
8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.
[Regression potential]
Since /proc/sys/kernel/moksbstate_disabled will not be present on older kernels, and /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 is always less authoritative than /proc/sys/kernel/moksbstate_disabled if present, I don't see any way that this could regress.
update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state. However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information. There are two that it tries to use:
- We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
- The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
Neither of these is guaranteed to be present on any given system. However, if present, the kernel variable should be *unconditionally* preferred over the efi "shadow" variable - because the kernel variable is immutable, whereas MokSBStateRT is just another nvram variable that things can overwrite (though they shouldn't).
We have heard at least one report internally of a system where something other than our shim is setting the value of MokSBStateRT and confusing update-secureboot-policy, so this will be a priority to also fix in SRU. |
|
| 2016-07-21 13:44:47 |
Adam Conrad |
shim-signed (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2016-07-21 13:44:49 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-07-21 13:44:51 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2016-07-21 13:44:57 |
Adam Conrad |
tags |
|
verification-needed |
|
| 2016-07-21 13:45:31 |
Adam Conrad |
shim-signed (Ubuntu Wily): status |
New |
Fix Committed |
|
| 2016-07-21 13:46:02 |
Adam Conrad |
shim-signed (Ubuntu Trusty): status |
New |
Fix Committed |
|
| 2016-07-21 13:47:32 |
Adam Conrad |
shim-signed (Ubuntu Precise): status |
New |
Fix Committed |
|
| 2016-07-21 18:21:38 |
Mathew Hodson |
shim-signed (Ubuntu): importance |
Undecided |
High |
|
| 2016-07-21 18:21:40 |
Mathew Hodson |
shim-signed (Ubuntu Precise): importance |
Undecided |
High |
|
| 2016-07-21 18:21:41 |
Mathew Hodson |
shim-signed (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2016-07-21 18:21:43 |
Mathew Hodson |
shim-signed (Ubuntu Wily): importance |
Undecided |
High |
|
| 2016-07-21 18:21:45 |
Mathew Hodson |
shim-signed (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2016-07-22 10:02:20 |
Shih-Yuan Lee |
tags |
verification-needed |
verification-done-trusty verification-needed |
|
| 2016-07-22 10:02:43 |
Shih-Yuan Lee |
tags |
verification-done-trusty verification-needed |
verification-done-trusty |
|
| 2016-07-22 10:03:27 |
Shih-Yuan Lee |
tags |
verification-done-trusty |
verification-done-trusty verification-needed-precise verification-needed-wily verification-needed-xenial |
|
| 2016-07-25 10:11:26 |
Shih-Yuan Lee |
tags |
verification-done-trusty verification-needed-precise verification-needed-wily verification-needed-xenial |
verification-done-trusty verification-done-xenial verification-needed-precise verification-needed-wily |
|
| 2016-07-26 03:42:21 |
Shih-Yuan Lee |
tags |
verification-done-trusty verification-done-xenial verification-needed-precise verification-needed-wily |
verification-done-trusty verification-done-wily verification-done-xenial verification-needed-precise |
|
| 2016-07-26 09:07:46 |
Shih-Yuan Lee |
tags |
verification-done-trusty verification-done-wily verification-done-xenial verification-needed-precise |
verification-done-precise verification-done-trusty verification-done-wily verification-done-xenial |
|
| 2016-07-26 09:08:02 |
Shih-Yuan Lee |
tags |
verification-done-precise verification-done-trusty verification-done-wily verification-done-xenial |
verification-done |
|
| 2016-07-26 12:32:15 |
Taihsiang Ho |
attachment added |
|
comment51.log.tar.gz https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1604873/+attachment/4707617/+files/comment51.log.tar.gz |
|
| 2016-07-27 10:00:24 |
Taihsiang Ho |
attachment added |
|
201508-18805-12.04.5.tar.gz https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1604873/+attachment/4708047/+files/201508-18805-12.04.5.tar.gz |
|
| 2016-07-28 16:38:38 |
Launchpad Janitor |
shim-signed (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2016-07-28 16:38:45 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-07-28 16:39:26 |
Launchpad Janitor |
shim-signed (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-07-29 01:03:15 |
Launchpad Janitor |
shim-signed (Ubuntu Wily): status |
Fix Committed |
Fix Released |
|
| 2016-09-15 18:03:08 |
Launchpad Janitor |
shim-signed (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2016-09-20 00:39:41 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/shim-signed |
|
