From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Garrett <matthew.garrett@nebula.com>,
Vivek Goyal <vgoyal@redhat.com>, Rob Landley <rob@landley.net>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@suse.de>,
linux-doc@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH v2] kexec: add sysctl to disable kexec
Date: Wed, 11 Dec 2013 09:52:55 -0800 [thread overview]
Message-ID: <87vbyvxojs.fsf@xmission.com> (raw)
In-Reply-To: <20131210001620.GA7938@www.outflux.net> (Kees Cook's message of "Mon, 9 Dec 2013 16:16:20 -0800")
Kees Cook <keescook@chromium.org> writes:
> For general-purpose (i.e. distro) kernel builds it makes sense to build with
> CONFIG_KEXEC to allow end users to choose what kind of things they want to do
> with kexec. However, in the face of trying to lock down a system with such
> a kernel, there needs to be a way to disable kexec (much like module loading
> can be disabled). Without this, it is too easy for the root user to modify
> kernel memory even when CONFIG_STRICT_DEVMEM and modules_disabled are
> set.
So let me get this straight. You object to what happens in sys_reboot
so you patch sys_kexec_load?
You give someone the privilege to boot whatever they want and yet you
don't want to support them booting whatever they want?
I'm sorry my brain is hurting trying to understand the logic of this
patch.
Eric
next prev parent reply other threads:[~2013-12-11 17:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 0:16 [PATCH v2] kexec: add sysctl to disable kexec Kees Cook
2013-12-10 0:34 ` H. Peter Anvin
2013-12-10 1:06 ` Kees Cook
2013-12-10 14:35 ` Vivek Goyal
2013-12-10 14:38 ` Vivek Goyal
2013-12-10 16:32 ` H. Peter Anvin
2013-12-10 18:33 ` Vivek Goyal
2013-12-10 18:54 ` H. Peter Anvin
2013-12-10 19:14 ` Vivek Goyal
2013-12-10 19:33 ` Kees Cook
2013-12-11 17:52 ` Eric W. Biederman [this message]
2013-12-11 21:13 ` Kees Cook
2013-12-11 23:15 ` Eric W. Biederman
2013-12-11 23:22 ` Kees Cook
2013-12-12 1:14 ` Eric W. Biederman
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=87vbyvxojs.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rob@landley.net \
--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