From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
David Howells <dhowells@redhat.com>
Cc: linux-fs@vger.kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, "Lee, Chun-Yi" <jlee@suse.com>,
Josh Boyer <jwboyer@fedoraproject.org>
Subject: Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module
Date: Tue, 13 Mar 2018 10:18:35 -0700 [thread overview]
Message-ID: <1520961515.5360.19.camel@HansenPartnership.com> (raw)
In-Reply-To: <20180313103803.13388-5-jlee@suse.com>
On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote:
> This patch adds the logic for checking the kernel module's hash
> base on blacklist. The hash must be generated by sha256 and enrolled
> to dbx/mokx.
>
> For example:
> sha256sum sample.ko
> mokutil --mokx --import-hash $HASH_RESULT
>
> Whether the signature on ko file is stripped or not, the hash can be
> compared by kernel.
What's the use case for this? We're already in trouble from the ODMs
for the size of dbx and its consumption of the extremely limited
variable space, so do we really have a use case for adding module
blacklist hashes to the UEFI variables given the space constraints (as
in one we can't do any other way)?
James
next prev parent reply other threads:[~2018-03-13 17:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 10:37 [PATCH 0/5 v2] Using the hash in MOKx to blacklist kernel module Lee, Chun-Yi
2018-03-13 10:37 ` [PATCH 1/5] MODSIGN: do not load mok when secure boot disabled Lee, Chun-Yi
2018-03-13 17:25 ` Ard Biesheuvel
2018-03-14 10:23 ` joeyli
2018-03-13 10:38 ` [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list Lee, Chun-Yi
2018-03-13 10:38 ` [PATCH 3/5] MODSIGN: load blacklist from MOKx Lee, Chun-Yi
2018-03-13 10:38 ` [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module Lee, Chun-Yi
2018-03-13 17:18 ` James Bottomley [this message]
2018-03-14 6:08 ` joeyli
2018-03-14 14:19 ` James Bottomley
2018-03-15 6:16 ` joeyli
2018-03-15 14:30 ` James Bottomley
2018-03-16 7:32 ` joeyli
2018-03-13 10:38 ` [PATCH 5/5] MODSIGN: check the attributes of db and mok Lee, Chun-Yi
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=1520961515.5360.19.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=jlee@suse.com \
--cc=joeyli.kernel@gmail.com \
--cc=jwboyer@fedoraproject.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-fs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).