From: Marco Stornelli <marco.stornelli@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
Chen Gong <gong.chen@linux.intel.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [PATCH 2/2] ramoops: remove module parameters
Date: Sat, 19 Nov 2011 10:25:25 +0100 [thread overview]
Message-ID: <4EC77605.5090605@gmail.com> (raw)
In-Reply-To: <1321644698-13677-3-git-send-email-keescook@chromium.org>
Il 18/11/2011 20:31, Kees Cook ha scritto:
> The ramoops driver is intended to be used with platforms that define
> persistent memory regions. If memory regions were configurable with
> module parameters, it would be possible to read some RAM regions via
> the pstore interface without access to /dev/mem (which would result
> in a loss of kernel memory privacy when a system is built with
> STRICT_DEVMEM), so remove this ability completely.
>
I don't like it very much. The loss of module parameters give us less
flexibility. The main goal of this driver is debug, so I think it should
be fast to use. I mean it's not more possible reserve a memory region
and load the module "on-the-fly", it needs a platform device, it's ok
but I think it's a little bit more complicated, (without talking about
platforms without a device tree source).
I don't understand the problem of strict devmem. We shouldn't use kernel
memory region but only reserved ones and the driver doesn't use the
request_mem_region_exclusive, am I wrong?
Marco
next prev parent reply other threads:[~2011-11-19 9:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-18 19:31 [PATCH 0/2 v2] ramoops: use pstore interface Kees Cook
2011-11-18 19:31 ` [PATCH 1/2] " Kees Cook
2011-11-18 19:31 ` [PATCH 2/2] ramoops: remove module parameters Kees Cook
2011-11-19 9:25 ` Marco Stornelli [this message]
2011-11-21 18:11 ` Kees Cook
2011-11-22 17:23 ` Marco Stornelli
2011-11-22 18:14 ` Kees Cook
2011-11-23 16:40 ` Marco Stornelli
-- strict thread matches above, loose matches on Subject: below --
2011-11-16 21:25 [PATCH 0/2] ramoops: use pstore interface Kees Cook
2011-11-16 21:25 ` [PATCH 2/2] ramoops: remove module parameters Kees Cook
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=4EC77605.5090605@gmail.com \
--to=marco.stornelli@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=gong.chen@linux.intel.com \
--cc=gregkh@suse.de \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=paul.gortmaker@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.