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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox