From: ebiederm@xmission.com (Eric W. Biederman)
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
David Howells <dhowells@redhat.com>,
kexec <kexec@lists.infradead.org>,
"Linux-Kernel\@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
Vivek Goyal <vgoyal@redhat.com>, Dave Young <dyoung@redhat.com>,
Petr Tesarik <ptesarik@suse.cz>
Subject: Re: kexec_load(2) bypasses signature verification
Date: Tue, 16 Jun 2015 14:38:31 -0500 [thread overview]
Message-ID: <87zj3zigug.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20150615200115.GG5003@thunk.org> (Theodore Ts'o's message of "Mon, 15 Jun 2015 16:01:15 -0400")
Adding Vivek as he is the one who implemented kexec_file_load.
I was hoping he would respond to this thread, and it looks like he
simply has not ever been Cc'd.
Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> The bits that actually read Secure Boot state out of the UEFI
>> variables, and apply protections to the machine to avoid compromise
>> under the SB threat model. Things like disabling the old kexec...
>
> I don't have any real interest in using Secure Boot, but I *am*
> interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> have something similar to what we have with signed modules in terms of
> CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> KEXEC_VERIFY_SIG. This would mean creating a separate flag
> independent of the one Linus suggested for Secure Boot, but since we
> have one for signed modules, we do have precedent for this sort of
> thing.
My overall request with respect to kexec has been that we implement
things that make sense outside of the bizarre threat model of the Linux
folks who were talking about secure boot.
nI have not navigated the labyrinth of config options but having a way to
only boot signed things with kexec seems a completely sensible way to
operate in the context of signed images.
I don't know how much that will help given that actors with sufficient
resources have demonstrated the ability to steal private keys, but
assuming binary signing is an effective technique (or why else do it)
then having an option to limit kexec to only loading signed images seems
sensible.
Eric
next prev parent reply other threads:[~2015-06-16 19:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 3:50 kexec_load(2) bypasses signature verification Theodore Ts'o
2015-06-15 12:14 ` Josh Boyer
2015-06-15 13:17 ` Theodore Ts'o
2015-06-15 13:37 ` Josh Boyer
2015-06-15 20:01 ` Theodore Ts'o
2015-06-16 19:38 ` Eric W. Biederman [this message]
2015-06-16 20:27 ` Vivek Goyal
2015-06-17 1:32 ` Eric W. Biederman
2015-06-17 1:47 ` Vivek Goyal
2015-06-18 1:16 ` Dave Young
2015-06-18 2:02 ` Dave Young
2015-06-18 13:30 ` Vivek Goyal
2015-06-18 14:41 ` Eric W. Biederman
2015-06-19 6:21 ` Dave Young
2015-06-19 8:18 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-25 8:48 ` Dave Young
2015-06-25 15:59 ` Vivek Goyal
2015-06-26 1:59 ` Dave Young
2015-06-19 7:04 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-17 3:26 ` Theodore Ts'o
2015-06-17 10:55 ` One Thousand Gnomes
2015-06-18 1:25 ` Dave Young
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=87zj3zigug.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=dhowells@redhat.com \
--cc=dyoung@redhat.com \
--cc=jwboyer@fedoraproject.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
/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