mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Bernhard Walle <bwalle@suse.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH 2/2] Add dev.mem.restricted sysctl
Date: Sun, 16 Nov 2008 01:36:20 -0800	[thread overview]
Message-ID: <20081116013620.5564de1e@infradead.org> (raw)
In-Reply-To: <20081116103005.72a28833@kopernikus.site>

On Sun, 16 Nov 2008 10:30:05 +0100
Bernhard Walle <bwalle@suse.de> wrote:

> * Arjan van de Ven [2008-11-15 19:49]:
> >
> > On Sun, 16 Nov 2008 01:03:43 +0100
> > Bernhard Walle <bwalle@suse.de> wrote:
> > 
> > > When CONFIG_STRICT_DEVMEM is set, live debugging is not possible
> > > with the crash utility (see http://people.redhat.com/~anderson).
> > > For distributors who ship a generic kernel it's difficult:
> > > Disabling CONFIG_STRICT_DEVMEM is possible, but in general the
> > > protection provided by CONFIG_STRICT_DEVMEM is useful. However,
> > > live debugging should be still neceessary.
> > > 
> > > This patch now adds a dev.mem.restricted sysctl that defaults to 0
> > > (off). When set to 1 (on), /dev/mem access is unrestricted and
> > > crash can be used.
> > 
> > sounds like a really bad idea to me.
> > If you want to use /dev/mem like this, don't enable the config
> > option to restrict it. Really.
> 
> So, what's that restriction really for? 

It's for not allowing something that you don't need, if you 
know you don't need it. Least privilege and all that.
(so that selinux can give X access to devices but not to all of memory.
I know Alan mentioned DMA but that's also a choice, a lot of the systems
on the market for the last year or two have an IOMMU that you can use
etc)
 
But if you do need it, then you do need it, simple as that.

(that leave the entire fun question of cache attributes but thats' a
whole different animal)

 
-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

      reply	other threads:[~2008-11-16  9:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-16  0:03 [RFC] " Bernhard Walle
2008-11-16  0:03 ` [PATCH 1/2] Unify devmem_is_allowed across architectures Bernhard Walle
2008-11-16  0:03 ` [PATCH 2/2] Add dev.mem.restricted sysctl Bernhard Walle
2008-11-16  0:07   ` Alan Cox
2008-11-16  0:09     ` Bernhard Walle
2008-11-16  0:12       ` Alan Cox
2008-11-16  0:11   ` Bernhard Walle
2008-11-16  0:33   ` Alexey Dobriyan
2008-11-16  9:28     ` Bernhard Walle
2008-11-16 10:13       ` Alexey Dobriyan
2008-11-16  3:49   ` Arjan van de Ven
2008-11-16  9:30     ` Bernhard Walle
2008-11-16  9:36       ` Arjan van de Ven [this message]

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=20081116013620.5564de1e@infradead.org \
    --to=arjan@infradead.org \
    --cc=bwalle@suse.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@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

all inboxes | Powered by JetHome®