linux-kernel - Re: [PATCH] certs: Add EFI_CERT_X509

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c33c8e3839a41e9654f41cc92c7231104931b1d7.camel@HansenPartnership.com>
Date:   Wed, 13 Jan 2021 15:56:39 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     David Howells <dhowells@...hat.com>, torvalds@...ux-foundation.org
Cc:     jarkko@...nel.org, eric.snowberg@...cle.com,
        ard.biesheuvel@...aro.org, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] certs: Add EFI_CERT_X509_GUID support for dbx entries

On Wed, 2021-01-13 at 13:40 +0000, David Howells wrote:
> Hi Linus,
> 
> Are you willing to take this between merge windows - or does it need
> to wait for the next merge window?  It's not technically a bug fix to
> the kernel, but it does have a CVE attached to it.
> 
> Note that I've also updated Jarkko's address in his Reviewed-by since
> his Intel address no longer works.

Sorry, late to the party.

I suppose I lost the argument that we shouldn't really be trusting any
certs from db when shim is in operation because they're all EFI binary
signing ones and will usually simply be the microsoft certificate and
possibly an OEM platform one and we're usually pivoting the root of
trust to the certificates in the MokList.

However, if we are going to do this, we should also be blacklisting the
certificates in MokListX which the OS sees through MokListXRT.  Since
MokListX is an essential piece of our revocation infrastructure it
should have been mentioned in the CVE but wasn't for some reason.

James