| Message ID | 20210517131848.61153-1-dimitri.ledkov@canonical.com |
|---|---|
| Headers | show |
| Series | Support importing mokx keys into revocation list from the mok table | expand |
On 17/05/2021 09:18, Dimitri John Ledkov wrote: > [Impact] > > * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. > > * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. > > * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. > > * However, it only does so by reading MokListXRT efi variable. > > * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. > > * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table > > * The above is known as CVE-2020-26541 > > * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. > > [Test Plan] > > * Boot kernel with 15.4 based Ubuntu shim > > * Install keyutils package > > * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. > > * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. > > [Where problems could occur] > > * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). > > [Other Info] > > * The patches to fix the above have been submitted upstream > > https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ > > https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ > > This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. > This looks like v2 of your previous set, so please use "PATCH v2" in subject and add a changelog (either in cover letter or in each patch itself). Best regards, Krzysztof
On Mon, May 17, 2021 at 02:18:46PM +0100, Dimitri John Ledkov wrote: > [Impact] > > * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. > > * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. > > * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. > > * However, it only does so by reading MokListXRT efi variable. > > * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. > > * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table > > * The above is known as CVE-2020-26541 > > * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. > > [Test Plan] > > * Boot kernel with 15.4 based Ubuntu shim > > * Install keyutils package > > * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. > > * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. > > [Where problems could occur] > > * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). > > [Other Info] > > * The patches to fix the above have been submitted upstream > > https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ > > https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ > > This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. The changes look generally okay to me, possibly some minor stylistic issues but I'm content to let upstream worry about that. Can you refresh the patches based on Krzysztof's feedback and resend? Then I think we should go ahead and apply them, and once a version is upstream we can replace these patches with those. Thanks, Seth
On 18/05/2021 05:56, Dimitri John Ledkov wrote: > [Impact] > > * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. > > * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. > > * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. > > * However, it only does so by reading MokListXRT efi variable. > > * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. > > * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table > > * The above is known as CVE-2020-26541 > > * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. > > [Test Plan] > > * Boot kernel with 15.4 based Ubuntu shim > > * Install keyutils package > > * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. > > * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. > > [Where problems could occur] > > * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). > > [Other Info] > > * The patches to fix the above have been submitted upstream > > https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ > > https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ > > BugLink: https://bugs.launchpad.net/bugs/1928679 > > This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. > > [ChangeLog] > > Changes since RFC patch: Thanks for changelog. This should be now: Changes since v2: Changes since RFC: > - bump patch version numbers, this is the third submission to kernel-team@ > - fix {} C coding style in blacklist.c, also resubmitted upstream > - fix commit message style to remove whitelines between tags > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Best regards, Krzysztof
On Tue, May 18, 2021 at 10:56:40AM +0100, Dimitri John Ledkov wrote: > [Impact] > > * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. > > * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. > > * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. > > * However, it only does so by reading MokListXRT efi variable. > > * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. > > * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table > > * The above is known as CVE-2020-26541 > > * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. > > [Test Plan] > > * Boot kernel with 15.4 based Ubuntu shim > > * Install keyutils package > > * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. > > * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. > > [Where problems could occur] > > * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). > > [Other Info] > > * The patches to fix the above have been submitted upstream > > https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ > > https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ > > BugLink: https://bugs.launchpad.net/bugs/1928679 > > This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. > > [ChangeLog] > > Changes since RFC patch: > - bump patch version numbers, this is the third submission to kernel-team@ > - fix {} C coding style in blacklist.c, also resubmitted upstream > - fix commit message style to remove whitelines between tags Acked-by: Seth Forshee <seth.forshee@canonical.com>
On Tue, May 18, 2021 at 10:56:40AM +0100, Dimitri John Ledkov wrote: > [Impact] > > * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. > > * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. > > * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. > > * However, it only does so by reading MokListXRT efi variable. > > * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. > > * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table > > * The above is known as CVE-2020-26541 > > * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. > > [Test Plan] > > * Boot kernel with 15.4 based Ubuntu shim > > * Install keyutils package > > * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. > > * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. > > [Where problems could occur] > > * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). > > [Other Info] > > * The patches to fix the above have been submitted upstream > > https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ > > https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ > > BugLink: https://bugs.launchpad.net/bugs/1928679 > > This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. > > [ChangeLog] > > Changes since RFC patch: > - bump patch version numbers, this is the third submission to kernel-team@ > - fix {} C coding style in blacklist.c, also resubmitted upstream > - fix commit message style to remove whitelines between tags Applied to unstable/master. Once something lands upstream, if there are any changes let's swap these out for the upstream versions. Thanks!
[Impact] * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. * However, it only does so by reading MokListXRT efi variable. * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table * The above is known as CVE-2020-26541 * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. [Test Plan] * Boot kernel with 15.4 based Ubuntu shim * Install keyutils package * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. [Where problems could occur] * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). [Other Info] * The patches to fix the above have been submitted upstream https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/ https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.ledkov@canonical.com/ This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. Dimitri John Ledkov (2): UBUNTU: SAUCE: integrity: Load mokx certs from the EFI MOK config table UBUNTU: SAUCE: integrity: add informational messages when revoking certs certs/blacklist.c | 4 +- .../platform_certs/keyring_handler.c | 1 + security/integrity/platform_certs/load_uefi.c | 74 ++++++++++--------- 3 files changed, 44 insertions(+), 35 deletions(-)