mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Bernhard Walle <bwalle@suse.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, crash-utility@redhat.com
Subject: Re: Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted
Date: Sun, 16 Nov 2008 17:03:06 +0000	[thread overview]
Message-ID: <20081116170306.5b3bc30a@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20081116171139.0456b1b2@kopernikus.site>

> > Which also doesn't explain what this turd is for.
> 
> Could we discuss more factual without words like "turd", please?

What else would you have me call it. It's junk.

> > The functionality provided by STRICT_DEVMEM is the same with it on or off
> > - absolutely *nothing*.
> 
> Even with SELinux?

As far as I can tell yes, and certainly with vendor shipped rulesets.

> > does compile it *out* and the overhead is gone totally for the many
> > embedded and other devices that don't use it.
> 
> For SELinux, yes. 

And for strict devmem but only before your patch.

> Oh well, I don't tell it our legal people if you would write SuSE
> instead of SUSE. Even not S.u.S.E. ;-)

Hehe ;)

> Well, if you let the CONFIG option there and only add the sysfs entry
> it does not. Even most embedded stuff is not x86.

These days a large amount of embedded is x86 and this is growing.

> > Even if you want to turd polish there are cleaner solutions. A process
> > with CAP_SYS_RAWIO can cheerfully bypass any restriction you try and
> > place so you could rip out all the sysctl crap and just say that
> > the /dev/mem restriction doesn't apply to a CAP_SYS_RAWIO process.
> 
> According to Arjan that does not work.

According to me CONFIG_STRICT_DEVMEM does not work either. Looking at the
X code most of it now tries really hard to use the right device files and
accesses. The window that is left is primarily the old ISA VGA hole and
even that could better be solved with a /dev/vgamem or similar that X
could use rather than /dev/mem.

Alan

  reply	other threads:[~2008-11-16 17:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-16 14:47 Bernhard Walle
2008-11-16 14:47 ` [PATCH 1/3] Unify devmem_is_allowed across architectures Bernhard Walle
2008-11-16 14:47 ` [PATCH 2/3] Add dev.mem.restricted sysctl Bernhard Walle
2008-11-16 15:07   ` Willy Tarreau
2008-11-16 14:47 ` [PATCH 3/3] Remove CONFIG_STRICT_DEVMEM Bernhard Walle
2008-11-16 15:09   ` Alan Cox
2008-11-16 15:21     ` Bernhard Walle
2008-11-16 15:46       ` Alan Cox
2008-11-17 13:57     ` David Howells
2008-11-16 15:07 ` Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted Alan Cox
2008-11-16 15:20   ` Bernhard Walle
2008-11-16 15:45     ` Alan Cox
2008-11-16 16:03       ` Arjan van de Ven
2008-11-16 16:09         ` Alan Cox
2008-11-16 16:19         ` Bernhard Walle
2008-11-16 16:11       ` Bernhard Walle
2008-11-16 17:03         ` Alan Cox [this message]
2008-11-16 15:39 ` Arjan van de Ven
2008-11-16 15:56   ` Bernhard Walle
2008-11-16 16:06     ` Arjan van de Ven
2008-11-16 20:32   ` H. Peter Anvin

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=20081116170306.5b3bc30a@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=bwalle@suse.de \
    --cc=crash-utility@redhat.com \
    --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®