Comment 11 for bug 1063061

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.