> On Sep 12, 2023, at 4:47 PM, Mimi Zohar wrote:
>
> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
>>
>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar wrote:
>>>
>>> On Tue, 2023-09-12 at 02:00 +, Eric Snowberg wrote:
>>>>
> On Sep 12, 2023, at 5:54 AM, Mimi Zohar wrote:
>
> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
>>
>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar wrote:
>>>
>>> On Mon, 2023-09-11 at 22:17 +, Eric Snowberg wrote:
>>>>
>
> On Sep 11, 2023, at 5:08 PM, Mimi Zohar wrote:
>
> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>>
>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün wrote:
>>>
>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>&g
> On Sep 11, 2023, at 4:04 PM, Jarkko Sakkinen wrote:
>
> On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
>> Hi Eric,
>>
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring if th
> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün wrote:
>
> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>> Hi Eric,
>>
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring i
> On Mar 15, 2021, at 12:01 PM, Mickaël Salaün wrote:
>
>
> On 15/03/2021 17:59, Eric Snowberg wrote:
>>
>>> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün wrote:
>>>
>>> From: Mickaël Salaün
>>>
>>> Add a kernel opt
which
> make sense because the descriptions are already viewable;
> * forbids key update (blacklist and asymmetric ones);
> * restricts kernel rights on the blacklist keyring to align with the
> root user rights.
>
> See help in tools/certs/print-cert-tbs-hash.sh .
>
ely create such hash.
>
> Cc: David Howells
> Cc: David Woodhouse
> Cc: Eric Snowberg
> Signed-off-by: Mickaël Salaün
> Reviewed-by: Jarkko Sakkinen
> Link: https://lore.kernel.org/r/20210312171232.2681989-2-...@digikod.net
Tested-by: Eric Snowberg
> ---
>
> C
> On Mar 13, 2021, at 1:13 AM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> If MOKx will be available thru a config table in the next shim,
>> I'll prepare a follow on patch to add this support.
>
> Can this go separately, or would it be better
> On Mar 12, 2021, at 4:53 PM, Dimitri John Ledkov
> wrote:
>
> On 12/03/2021 21:49, Eric Snowberg wrote:
>>
>>> On Mar 12, 2021, at 11:39 AM, Dimitri John Ledkov
>>> wrote:
>>>
>>> On 25/02/2021 20:59, David Howells wrote:
>>&g
> On Mar 12, 2021, at 11:39 AM, Dimitri John Ledkov
> wrote:
>
> On 25/02/2021 20:59, David Howells wrote:
>> From: Eric Snowberg
>>
>> During boot the Secure Boot Forbidden Signature Database, dbx,
>> is loaded into the blacklist keyring. Systems bo
> On Mar 10, 2021, at 12:43 PM, Jarkko Sakkinen wrote:
>
> On Thu, Mar 04, 2021 at 12:50:30PM -0500, Eric Snowberg wrote:
>> Fix a build issue when x509_revocation_list is not defined.
>>
>> $ make ARCH=x86_64 O=build64 all
>>
>> EXTRACT_CERTS
> On Mar 10, 2021, at 2:08 PM, David Howells wrote:
>
> Can you check this patch? I rolled your changes into it.
Looks good to me, thanks.
> On Mar 5, 2021, at 2:50 PM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> @@ -11,7 +11,7 @@ hostprogs-always-$(CONFIG_ASN1)
>> += asn1_compiler
>> hostprogs-always-$(CONFIG_MODULE_SIG_FORMAT) +=
://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m562c1b27bf402190e7bb573ad20eff5b6310d08f
[2]
https://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m07e258bf019ccbac23820fad5192ceffa74fc6ab
Reported-by: Randy Dunlap
Signed-off-by: Eric Snowberg
> On Mar 3, 2021, at 2:24 AM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> +ifeq ($(CONFIG_SYSTEM_REVOCATION_LIST),y)
>> +obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += revocation_certificates.o
>> +endif
>
> Should the ifeq be referring to CONFI
://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m562c1b27bf402190e7bb573ad20eff5b6310d08f
[2]
https://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m07e258bf019ccbac23820fad5192ceffa74fc6ab
Reported-by: Randy Dunlap
Signed-off-by: Eric
.@infradead.org/
> [4]
> Link: https://lore.kernel.org/r/20210225125638.1841436-1-a...@kernel.org/ [5]
>
> David
> ---
> Eric Snowberg (4):
> certs: Add EFI_CERT_X509_GUID support for dbx entries
> certs: Move load_system_certificate_list to a common function
>
> On Feb 24, 2021, at 3:51 AM, David Howells wrote:
>
> How about these changes?
>
> I've added an extra config option to turn on SYSTEM_REVOCATION_LIST support.
I believe this is ok. However currently, whenever the kernel finds either a
EFI_CERT_SHA256_GUID or EFI_CERT_X509_SHA256_GUID ent
> On Feb 23, 2021, at 4:47 PM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> The kernel test robot reports when building with Kconfig
>> CONFIG_INTEGRITY_PLATFORM_KEYRING defined and
>> CONFIG_SYSTEM_DATA_VERIFICATION undefined:
>>
> On Feb 21, 2021, at 4:17 AM, Mickaël Salaün wrote:
>
> David, Eric, what is the status of this patch series?
All the previous issues I had identified have been resolved, so LGTM.
> On 10/02/2021 13:04, Mickaël Salaün wrote:
>> This new patch series is a rebase on David Howells's keys-misc b
:(is_key_on_revocation_list) in archive certs/built-in.a
Make CONFIG_SYSTEM_DATA_VERIFICATION a dependency for validate_trust.
Reported-by: kernel test robot
Signed-off-by: Eric Snowberg
---
certs/blacklist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/certs/blacklist.h b/certs
> On Feb 6, 2021, at 11:30 AM, Mickaël Salaün wrote:
>
> On 06/02/2021 02:14, Eric Snowberg wrote:
>
>> I have done some additional testing, I am seeing a regression. The blacklist
>> keyring is no longer picking up any of the hashes from the dbx during boot.
>&g
> On Feb 5, 2021, at 3:27 AM, Mickaël Salaün wrote:
>
>
> On 05/02/2021 01:24, Eric Snowberg wrote:
>>
>>> On Feb 4, 2021, at 1:26 AM, Mickaël Salaün wrote:
>>>
>>>
>>> On 04/02/2021 04:53, Eric Snowberg wrote:
>>
> On Feb 4, 2021, at 1:26 AM, Mickaël Salaün wrote:
>
>
> On 04/02/2021 04:53, Eric Snowberg wrote:
>>
>>> On Feb 3, 2021, at 11:49 AM, Mickaël Salaün wrote:
>>>
>>> This looks good to me, and it still works for my use case. Eric's
-security-module/msg40262.html
> On 03/02/2021 17:26, David Howells wrote:
>>
>> Eric Snowberg wrote:
>>
>>> This is the fifth patch series for adding support for
>>> EFI_CERT_X509_GUID entries [1]. It has been expanded to not only include
>
list(const u8 cert_list[],
^
static
1 warning generated.
Fix the warning by including the header file.
Signed-off-by: Eric Snowberg
Reported-by: kernel test robot
---
certs/common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/certs/common.c b/certs/common.c
index 83800f51a1a1..16
> On Jan 28, 2021, at 8:58 AM, David Howells wrote:
>
> Nayna wrote:
>
>> Thanks Eric for clarifying. I was confusing it with with the broader meaning
>> of revocation i.e. certificate revocation list. To avoid similar confusion in
>> the future, I wonder if we should call it as 'blocklist' o
> On Jan 28, 2021, at 8:16 AM, David Howells wrote:
>
> Which tree do you envision this going through? EFI or keyrings - or are you
> going to ask Linus to pull it directly? I can pull it if it should go through
> the keyrings tree.
I was thinking it would go thru your tree, since a majority
> On Jan 27, 2021, at 8:54 PM, Nayna wrote:
>
>
> On 1/22/21 1:10 PM, Eric Snowberg wrote:
>> This fixes CVE-2020-26541.
>>
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of now
>> revoked signatures and keys previously approved to b
> On Jan 27, 2021, at 7:03 AM, Mimi Zohar wrote:
>
> [Cc'ing linux-integrity]
>
> On Wed, 2021-01-27 at 11:46 +, David Howells wrote:
>> Jarkko Sakkinen wrote:
>>
I suppose a user space tool could be created. But wouldn’t what is
currently done in the kernel in this area need t
mokx into the blacklist keyring during boot.
Signed-off-by: Eric Snowberg
Suggested-by: James Bottomley
---
security/integrity/platform_certs/load_uefi.c | 20 +--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b
in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
Reviewed-by: Jarkko Sakkinen
Signed-off-by: David Howells
---
v5: Function name changes done by David Howells
---
certs/blacklist.c | 32
]
https://patchwork.kernel.org/project/linux-security-module/patch/20200916004927.64276-1-eric.snowb...@oracle.com/
[2] https://lore.kernel.org/patchwork/cover/1315485/
Eric Snowberg (4):
certs: Add EFI_CERT_X509_GUID support for dbx entries
certs: Move load_system_certificate_list to a common
Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,
this option should be the filename of a PEM-formated file containing
X.509 certificates to be included in the default blacklist keyring.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Kconfig
Move functionality within load_system_certificate_list to a common
function, so it can be reused in the future.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Makefile | 2 +-
certs/common.c | 56 ++
certs/common.h
> On Jan 20, 2021, at 4:26 AM, Jarkko Sakkinen wrote:
>
> On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
>>
>>> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>>>
>>> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrot
> On Jan 15, 2021, at 10:21 AM, James Bottomley
> wrote:
>
> On Tue, 2020-09-15 at 20:49 -0400, Eric Snowberg wrote:
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of
>> now revoked signatures and keys previously approved to boot with UEFI
>
> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>
> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:
>>
>>> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
>>> wrote:
>>>
>>> On Tue, Jan 12, 2021 at 02:57:39PM +0
> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
> wrote:
>
> On Tue, Jan 12, 2021 at 02:57:39PM +, David Howells wrote:
>> Eric Snowberg wrote:
>>
>>>> On Dec 10, 2020, at 2:49 AM, David Howells wrote:
>>>>
>>>> Eric Snowber
d appreciate any feedback on that series as well.
Thanks
> David
> ---
> commit 8913866babb96fcfe452aac6042ca8862d4c0b53
> Author: Eric Snowberg
> Date: Tue Sep 15 20:49:27 2020 -0400
>
>certs: Add EFI_CERT_X509_GUID support for dbx entries
>
>The Secure Boo
> On Dec 10, 2020, at 2:49 AM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
>> is found, it is added as an asymmetrical key to the .blacklist keyring.
>> Anytime the .platform ke
> On Sep 30, 2020, at 3:02 PM, Jarkko Sakkinen
> wrote:
>
> On Wed, Sep 30, 2020 at 04:15:07PM -0400, Eric Snowberg wrote:
>> Move functionality within load_system_certificate_list to a common
>> function, so it can be reused in the future.
>>
>> Signed-
Move functionality within load_system_certificate_list to a common
function, so it can be reused in the future.
Signed-off-by: Eric Snowberg
---
certs/Makefile | 2 +-
certs/common.c | 56 ++
certs/common.h | 9 +++
certs
the ability to also preload EFI_CERT_X509_GUID dbx entries.
This series can be applied on its own; however to use preloaded
revocation certificates, [1] should be applied first.
[1] https://www.spinics.net/lists/keyrings/msg08422.html
Eric Snowberg (2):
certs: Move load_system_certificate_list
Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,
this option should be the filename of a PEM-formated file containing
X.509 certificates to be included in the default blacklist keyring.
Signed-off-by: Eric Snowberg
---
certs/Kconfig | 8
certs/Makefile
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
---
v4:
Remove unneeded symbol export found by Jarkko Sakkinen
v3:
Fixed an issue when CONFIG_PKCS7_MESSAGE_PARSER is not builtin and defined
as a module instead, pointed out by Randy Dunlap
v2
> On Sep 14, 2020, at 12:12 PM, Jarkko Sakkinen
> wrote:
>
> On Fri, Sep 11, 2020 at 02:22:30PM -0400, Eric Snowberg wrote:
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of now
>> revoked signatures and keys previously approved to boot with UEF
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
---
v3:
Fixed an issue when CONFIG_PKCS7_MESSAGE_PARSER is not builtin and defined
as a module instead, pointed out by Randy Dunlap
v2:
Fixed build issue reported by kernel test robot
Commit
> On Sep 9, 2020, at 11:40 AM, Randy Dunlap wrote:
>
> On 9/9/20 10:27 AM, Eric Snowberg wrote:
>> diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
>> index 38ec7f5f9041..d8f2e0fdfbf4 100644
>> --- a/include/crypto/pkcs7.h
>> +++ b/include/c
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
---
v2:
Fixed build issue reported by kernel test robot
Commit message update (suggested by Jarkko Sakkinen)
---
certs/blacklist.c | 36 +++
certs
> On Sep 4, 2020, at 6:59 AM, Jarkko Sakkinen
> wrote:
>
> On Tue, Sep 01, 2020 at 12:51:43PM -0400, Eric Snowberg wrote:
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of now
>> revoked signatures and keys previously approved to boot with UEF
.blacklist keyring are referenced, if a matching key is found, the
key will be rejected.
Signed-off-by: Eric Snowberg
---
certs/blacklist.c | 36 +++
certs/system_keyring.c| 6
include/keys/system_keyring.h | 11
Commit-ID: b84a64fad40637b1c9fa4f4dbf847a23e29e672b
Gitweb: https://git.kernel.org/tip/b84a64fad40637b1c9fa4f4dbf847a23e29e672b
Author: Eric Snowberg
AuthorDate: Thu, 29 Nov 2018 18:12:20 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 08:30:07 +0100
x86/efi: Allocate e820
54 matches
Mail list logo
