mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Pearson <markpearson@lenovo.com>
To: "Jeremy Kerr" <jk@codeconstruct.com.au>,
	"Thomas Weißschuh" <thomas@t-8ch.de>,
	"Mickaël Salaün" <mic@digikod.net>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>, <keyrings@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>
Subject: Re: [External] Re: [BUG] blacklist: Problem blacklisting hash (-13) during boot
Date: Tue, 7 Mar 2023 08:45:38 -0500	[thread overview]
Message-ID: <1bb01e6c-3829-6af4-b2c5-5dc82bd75b72@lenovo.com> (raw)
In-Reply-To: <c5d674bd67735de460b19fd955f718bf8b604c1d.camel@codeconstruct.com.au>

Hi all,

On 2/27/23 09:36, Jeremy Kerr wrote:
> Hi Mark,
>
>
>> I've been looking at this and the FW team are claiming that it's not
>> caused by duplicate entries in the dbx table, which is honestly a bit
>> confusing.
>>
>> We've been doing some more digging - but is there a possibility this
>> is caused by something else?
> I can't quite trace where the EACCES is coming from, I can't see any
> obvious causes there - the blacklist key type doesn't have an ->update
> operation, and the assoc_array insert doesn't look like it would fail.
>
> However: if I delete one of the duplicate keys using the bios UI, then
> the number of errors logged decreases by one.
>
Got to the bottom of this, after a longer exercise than it should have 
been. I have some answers.

The entries are indeed duplicated in our DBX. The reason for this is the 
FW team took three different DBX list published by UEFI forum in 
different time series and combined them. They did this as they found 
some distinct hashes in previously published ones and chose to combine 
them for safety/completeness sake.

I haven't myself dug into the revocation lists hosted on 
https://uefi.org/revocationlistfile but it sounds like there was some 
churn there? The FW team agreed that duplicates should not have been 
created.

The FW team have pushed back on doing another update for this generation 
of platforms. Updating the DBX to make these changes, particularly 
removing entries, will apparently be difficult. I prodded a bit into the 
details but given the issue is essentially cosmetic I do understand 
their concerns (the last DBX update caused enough issues...I'm not sure 
I want to go through it again in a hurry).

They have said they will fix the tables for future platforms.

Hope that helps

Mark



      reply	other threads:[~2023-03-07 13:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-15  3:16 Thomas Weißschuh
2022-11-04 17:03 ` Mickaël Salaün
2022-11-04 19:11   ` Thomas Weißschuh
2022-11-04 20:12     ` [External] " Mark Pearson
2023-02-26  3:42       ` Jeremy Kerr
2023-02-26  4:28         ` Thomas Weißschuh 
2023-02-27  1:42           ` Jeremy Kerr
2023-02-27 13:38         ` Mark Pearson
2023-02-27 14:36           ` Jeremy Kerr
2023-03-07 13:45             ` Mark Pearson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1bb01e6c-3829-6af4-b2c5-5dc82bd75b72@lenovo.com \
    --to=markpearson@lenovo.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=jarkko@kernel.org \
    --cc=jk@codeconstruct.com.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=thomas@t-8ch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®