All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Yinghai Lu <yinghai@kernel.org>
Subject: Re: RFC: banning device driver reserved resources from /dev/mem
Date: Mon, 6 Oct 2008 07:23:37 +0200	[thread overview]
Message-ID: <20081006052337.GE2186@elte.hu> (raw)
In-Reply-To: <20081005180154.7cc12486@infradead.org>


* Arjan van de Ven <arjan@infradead.org> wrote:

> From: Arjan van de Ven <arjan@linux.intel.com>
> Date: Sun, 5 Oct 2008 18:00:15 -0700
> Subject: [PATCH] resource: don't allow /dev/mem access reserved resources
> 
> Device drivers that use pci_request_regions() (and similar APIs) have a
> reasonable expectation that they are the only ones accessing their device.
> As part of the e1000e hunt, we were afraid that some userland (X or some
> bootsplash stuff) was mapping the MMIO region, that the driver thought it
> had exclusively, via /dev/mem.
> 
> This patch adds, to the existing config option to restrict /dev/mem, the
> reserved regions to the "banned from /dev/mem use" list, so now
> both kernel memory and device-exclusive MMIO regions are banned.
> 
> The introduced iomem_is_reserved() function is also planned to be used
> for other patches in 2.6.28 (pci_ioremap) so is exported here as part
> of being introduced.
> 
> Signed-of-by: Arjan van de Ven <arjan@linux.intel.com>
> ---
>  arch/x86/mm/init_32.c  |    2 ++
>  arch/x86/mm/init_64.c  |    2 ++
>  include/linux/ioport.h |    1 +
>  kernel/resource.c      |   32 ++++++++++++++++++++++++++++++++
>  4 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index 63b71d3..c98f5e8 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -329,6 +329,8 @@ int devmem_is_allowed(unsigned long pagenr)
>  {
>  	if (pagenr <= 256)
>  		return 1;
> +	if (iomem_is_reserved(pagenr << PAGE_SHIFT))
> +		return 0;

looks good and useful to me. One small request: could you please stick a 
big fat WARN_ONCE() into this codepath as well?

and it's properly dependent on CONFIG_STRICT_DEVMEM=y [which is 
default-off], so it's not a legacy ABI breaker either.

another small detail:

> +int iomem_is_reserved(u64 addr)
> +{
> +     struct resource *p = &iomem_resource;
> +     int err = 0;
> +     loff_t l;
> +     int size= PAGE_SIZE;
> +
> +     read_lock(&resource_lock);
> +     for (p = p->child; p ; p = r_next(NULL, p, &l)) {
> +             /*
> +              * We can probably skip the resources without
> +              * IORESOURCE_IO attribute?
> +              */
> +             if (p->start >= addr + size)
> +                     continue;

do we want to skip all resources that are not IORESOURCE_MEM? Same holds 
for iomem_map_sanity_check(), introduced in tip/core/resources:

 379daf6: IO resources, x86: ioremap sanity check to catch mapping requests exceeding the BAR sizes

on which you seem to have based iomem_is_reserved().

Perhaps even base both iomem_map_sanity_check() and iomem_is_reserved() 
on a single helper function, and unify the iterator and the overlap 
check? The two have a very similar purpose.

	Ingo

  reply	other threads:[~2008-10-06  5:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06  1:01 RFC: banning device driver reserved resources from /dev/mem Arjan van de Ven
2008-10-06  5:23 ` Ingo Molnar [this message]
2008-10-06  5:26   ` Arjan van de Ven
2008-10-06  9:27 ` Alan Cox
2008-10-06 13:40   ` Maxim Levitsky
2008-10-06 13:48     ` Alan Cox
2008-10-06 13:52       ` Arjan van de Ven
2008-10-06 14:01         ` Alan Cox
2008-10-06 14:05           ` Arjan van de Ven
2008-10-06 14:14             ` Alan Cox
2008-10-06 14:24               ` Arjan van de Ven
2008-10-06 14:38                 ` Alan Cox
2008-10-06 14:57                   ` Arjan van de Ven
2008-10-06 15:29                     ` Alan Cox

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=20081006052337.GE2186@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@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 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.