I've verified that the patch enables the expected interface to EFI variables. Preparing a test KEK update and PK update, I get the following output from sbkeysync --verbose:
$ sudo sbkeysync --verbose --keystore keydb
Filesystem keystore:
keydb/KEK/test.KEK-update [3076 bytes]
keydb/PK/test.PK-update [3076 bytes]
firmware keys:
PK:
/CN=DO NOT TRUST - PK
KEK:
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation KEK CA 2011
db:
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Testing Root Certificate Authority 2010
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows PCA 2010
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011
dbx:
0000000000000000000000000000000000000000000000000000000000000000
filesystem keys:
PK:
/C=US/ST=Oregon/L=Portland/O=Canonical Ltd./OU=Ubuntu Engineering/CN=Steve's test <email address hidden>
from keydb/PK/test.PK-update
KEK:
/C=US/ST=Oregon/L=Portland/O=Canonical Ltd./OU=Ubuntu Engineering/CN=Steve's test <email address hidden>
from keydb/KEK/test.KEK-update
db:
dbx:
New keys in filesystem:
keydb/KEK/test.KEK-update
keydb/PK/test.PK-update
Inserting key update keydb/KEK/test.KEK-update into KEK
Error writing key update: Permission denied
Error syncing keystore file keydb/KEK/test.KEK-update
$
The provided interface works as expected in this test case; the write is blocked because Secure Boot is enabled and the update is not signed with the platform key, so this is the expected error. I don't have time at the moment to test that a properly-authenticated write succeeds, but I don't think testing that is required to confirm that the kernel change is correct. Marking verification-done.
I've verified that the patch enables the expected interface to EFI variables. Preparing a test KEK update and PK update, I get the following output from sbkeysync --verbose:
$ sudo sbkeysync --verbose --keystore keydb KEK/test. KEK-update [3076 bytes] PK/test. PK-update [3076 bytes] US/ST=Washingto n/L=Redmond/ O=Microsoft Corporation/ CN=Microsoft Corporation KEK CA 2011 US/ST=Washingto n/L=Redmond/ O=Microsoft Corporation/ CN=Microsoft Corporation UEFI CA 2011 US/ST=Washingto n/L=Redmond/ O=Microsoft Corporation/ CN=Microsoft Testing Root Certificate Authority 2010 US/ST=Washingto n/L=Redmond/ O=Microsoft Corporation/ CN=Microsoft Windows PCA 2010 US/ST=Washingto n/L=Redmond/ O=Microsoft Corporation/ CN=Microsoft Windows Production PCA 2011 000000000000000 000000000000000 000000000000000 00000000 US/ST=Oregon/ L=Portland/ O=Canonical Ltd./OU=Ubuntu Engineering/ CN=Steve' s test <email address hidden> test.PK- update US/ST=Oregon/ L=Portland/ O=Canonical Ltd./OU=Ubuntu Engineering/ CN=Steve' s test <email address hidden> test.KEK- update KEK/test. KEK-update PK/test. PK-update test.KEK- update into KEK test.KEK- update
Filesystem keystore:
keydb/
keydb/
firmware keys:
PK:
/CN=DO NOT TRUST - PK
KEK:
/C=
db:
/C=
/C=
/C=
/C=
dbx:
00000000000
filesystem keys:
PK:
/C=
from keydb/PK/
KEK:
/C=
from keydb/KEK/
db:
dbx:
New keys in filesystem:
keydb/
keydb/
Inserting key update keydb/KEK/
Error writing key update: Permission denied
Error syncing keystore file keydb/KEK/
$
The provided interface works as expected in this test case; the write is blocked because Secure Boot is enabled and the update is not signed with the platform key, so this is the expected error. I don't have time at the moment to test that a properly- authenticated write succeeds, but I don't think testing that is required to confirm that the kernel change is correct. Marking verification-done.