From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1F17C433DB for ; Wed, 10 Feb 2021 12:16:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 852AD64DFF for ; Wed, 10 Feb 2021 12:16:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231649AbhBJMPn (ORCPT ); Wed, 10 Feb 2021 07:15:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbhBJMN3 (ORCPT ); Wed, 10 Feb 2021 07:13:29 -0500 Received: from smtp-42ac.mail.infomaniak.ch (smtp-42ac.mail.infomaniak.ch [IPv6:2001:1600:4:17::42ac]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A40CDC06178A for ; Wed, 10 Feb 2021 04:08:21 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4DbJRS2vZ7zMpnnY; Wed, 10 Feb 2021 13:07:32 +0100 (CET) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4DbJRP6qQzzlh8TJ; Wed, 10 Feb 2021 13:07:29 +0100 (CET) Subject: =?UTF-8?Q?Re=3a_Conflict_with_Micka=c3=abl_Sala=c3=bcn=27s_blacklis?= =?UTF-8?Q?t_patches_=5bwas_=5bPATCH_v5_0/4=5d_Add_EFI=5fCERT=5fX509=5fGUID_?= =?UTF-8?Q?support_for_dbx/mokx_entries=5d?= From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Eric Snowberg , David Howells Cc: dwmw2@infradead.org, Jarkko Sakkinen , James.Bottomley@HansenPartnership.com, masahiroy@kernel.org, michal.lkml@markovi.net, jmorris@namei.org, serge@hallyn.com, ardb@kernel.org, Mimi Zohar , lszubowi@redhat.com, javierm@redhat.com, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-security-module@vger.kernel.org, Tyler Hicks References: <20210122181054.32635-1-eric.snowberg@oracle.com> <1103491.1612369600@warthog.procyon.org.uk> <10e6616e-0598-9f33-2de9-4a5268bba586@digikod.net> <7924ce4c-ea94-9540-0730-bddae7c6af07@digikod.net> <188DE1AF-A011-4631-B88A-2C4324DA013B@oracle.com> <99066eb7-53ac-41b0-46cf-36ea3d7f6590@digikod.net> <74EC102D-BD18-4863-A7FB-C88439654C8C@oracle.com> <456712ef-1349-ffe2-9e34-7d49848980ff@digikod.net> Message-ID: <999f0763-b1c1-a9ad-0efe-d3e148663ced@digikod.net> Date: Wed, 10 Feb 2021 13:07:59 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: <456712ef-1349-ffe2-9e34-7d49848980ff@digikod.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On 09/02/2021 22:53, Mickaël Salaün wrote: > > On 09/02/2021 00:05, Eric Snowberg wrote: >> >>> 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. >>>> I backed out the merge with my changes (fdbbe7ceeb95090d09c33ce0497e0394c82aa33d) >>>> and still see the regression. I then backed out Mickaël merge >>>> (5bf1adccf5c41dbdd51d1f4de220d335d9548598) and it fixes the regression. >>>> >>>> On a x86 with the updated dbx from uefi.org, I’d expect to see 234 bin hash entries >>>> in the blacklist keyring. With the current merged code, there is none. >>> >>> Hum, I missed a part in refactoring (commit >>> f78e50c8f750c0ac6767ac1ed006360cf77c56c4). :/ >>> Could you please test the following patch? >>> >>> diff --git a/certs/blacklist.c b/certs/blacklist.c >>> index 07c592ae5307..f998a2e85ddc 100644 >>> --- a/certs/blacklist.c >>> +++ b/certs/blacklist.c >>> @@ -197,13 +197,16 @@ int mark_hash_blacklisted(const u8 *hash, size_t >>> hash_len, >>> enum blacklist_hash_type hash_type) >>> { >>> const char *buffer; >>> + int err; >>> >>> buffer = get_raw_hash(hash, hash_len, hash_type); >>> if (IS_ERR(buffer)) >>> return PTR_ERR(buffer); >>> + err = mark_raw_hash_blacklisted(buffer); >>> kfree(buffer); >>> - return 0; >>> + return err; >>> } >> >> I applied this patch, it works better, but there is still a regression. >> Most of the hashes show up in the blacklist keyring now. However some >> do not, here is what I see in the log during boot: >> >> [ 2.321876] blacklist: Problem blacklisting hash (-13) >> [ 2.322729] blacklist: Problem blacklisting hash (-13) >> [ 2.323549] blacklist: Problem blacklisting hash (-13) >> [ 2.324369] blacklist: Problem blacklisting hash (-13) >> >>> Is it possible to test these kind of dbx blacklist with Qemu? >> >> Yes, just use OVMF. >> > > My changes (with the fix) don't change the previous semantic. I just > tested without my changes and with my changes (and the fix), and I get > the same result: 184 bin hashes with > https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin > > Could you please re-test and if there is still an issue bisect and share > the certificates causing this issue? > > David, do you want me to send the two new patches or an updated full > patch series? > I found the issue and fixed it in a new patch series: https://lore.kernel.org/lkml/20210210120410.471693-1-mic@digikod.net/