linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Tue, 22 Nov 2011 18:23:06 +0100	[thread overview]
Message-ID: <4ECBDA7A.80504@gmail.com> (raw)
In-Reply-To: <CAGXu5j+Dh2jbAymcreOwX_T6=7FA8bOuwUFnwshdsVonAD5_EA@mail.gmail.com>

Il 21/11/2011 19:11, Kees Cook ha scritto:
> On Sat, Nov 19, 2011 at 1:25 AM, Marco Stornelli
> <marco.stornelli@gmail.com>  wrote:
>> 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?
>
> Hmmm, maybe I'm reading it backwards, but I think we want it to use
> ..._exclusive().
>
> int devmem_is_allowed(unsigned long pagenr)
> {
>          if (pagenr<= 256)
>                  return 1;
>          if (iomem_is_exclusive(pagenr<<  PAGE_SHIFT))
>                  return 0;
>          if (!page_is_ram(pagenr))
>                  return 1;
>          return 0;
> }
>
> If the region is exclusive, access is not allowed (return 0). ramoops
> currently uses request_mem_region() instead of
> request_mem_region_exclusive(). If we made that switch, I think I'd be
> happy. Would this create some problem I'm not seeing?
>
> -Kees
>

I don't understand why we should use the exclusive version, to protect 
debug data? You should provide a more valid reason to change, because 
the fact you will be happier with this change is not enough for me :)

Marco

  reply	other threads:[~2011-11-22 17:29 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
2011-11-21 18:11     ` Kees Cook
2011-11-22 17:23       ` Marco Stornelli [this message]
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=4ECBDA7A.80504@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 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).