From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: parabelboi@bopserverein.de, Christian Krafft <krafft@de.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
Date: Tue, 19 Feb 2008 07:42:03 +1100 [thread overview]
Message-ID: <1203367323.6740.21.camel@pasglop> (raw)
In-Reply-To: <20080218211519.2b159ade@hyperion.delvare>
> Maybe Christian's patch can be improved to not do the check on these?
> As long as /dev/port exists, it seems reasonable that the kernel should
> behave, no matter what I/O ports are accessed from user-space.
nonsense.
/dev/mem exists for example, but you are still not supposed to go
bang all over the place in it.
> > I hate that sensors_detect.. or for that matter any other userland code
> > that pokes random ports like that. It should die.
>
> What do you propose as a replacement?
Dunno, something less scary, like knowing where your sensors are on a
given machine... honestly, it's just scary the risk you guys are taking
by banging random IO ports.
At the very least, that shouldn't be done on non-x86.
> And how is userland code poking at random ports different from kernel
> code poking at random ports? We could move sensors-detect inside the
> kernel (and I have some plan to do that) but I fail to see how this
> would solve this particular problem.
It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: Christian Krafft <krafft@de.ibm.com>,
linux-kernel@vger.kernel.org, parabelboi@bopserverein.de,
linuxppc-dev@ozlabs.org
Subject: Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
Date: Tue, 19 Feb 2008 07:42:03 +1100 [thread overview]
Message-ID: <1203367323.6740.21.camel@pasglop> (raw)
In-Reply-To: <20080218211519.2b159ade@hyperion.delvare>
> Maybe Christian's patch can be improved to not do the check on these?
> As long as /dev/port exists, it seems reasonable that the kernel should
> behave, no matter what I/O ports are accessed from user-space.
nonsense.
/dev/mem exists for example, but you are still not supposed to go
bang all over the place in it.
> > I hate that sensors_detect.. or for that matter any other userland code
> > that pokes random ports like that. It should die.
>
> What do you propose as a replacement?
Dunno, something less scary, like knowing where your sensors are on a
given machine... honestly, it's just scary the risk you guys are taking
by banging random IO ports.
At the very least, that shouldn't be done on non-x86.
> And how is userland code poking at random ports different from kernel
> code poking at random ports? We could move sensors-detect inside the
> kernel (and I have some plan to do that) but I fail to see how this
> would solve this particular problem.
It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
Ben.
next prev parent reply other threads:[~2008-02-18 20:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 17:28 [Patch 0/2] add check_legacy_ioport calls to prevent oops Christian Krafft
2008-02-13 17:28 ` Christian Krafft
2008-02-13 17:35 ` [Patch 0/2] powerpc: avoid userspace poking to legacy ioports Christian Krafft
2008-02-13 20:42 ` Benjamin Herrenschmidt
2008-02-13 20:42 ` Benjamin Herrenschmidt
2008-02-13 23:07 ` Arnd Bergmann
2008-02-13 23:07 ` Arnd Bergmann
2008-02-18 20:15 ` Jean Delvare
2008-02-18 20:15 ` Jean Delvare
2008-02-18 20:42 ` Benjamin Herrenschmidt [this message]
2008-02-18 20:42 ` Benjamin Herrenschmidt
2008-02-18 20:58 ` Jean Delvare
2008-02-18 20:58 ` Jean Delvare
2008-02-18 21:04 ` Arjan van de Ven
2008-02-18 21:04 ` Arjan van de Ven
2008-02-18 21:05 ` Benjamin Herrenschmidt
2008-02-18 21:05 ` Benjamin Herrenschmidt
2008-02-13 17:37 ` [Patch 2/2] powerpc: i2c-isa: add access check " Christian Krafft
2008-02-18 13:31 ` Jean Delvare
2008-02-18 13:31 ` Jean Delvare
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=1203367323.6740.21.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=khali@linux-fr.org \
--cc=krafft@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=parabelboi@bopserverein.de \
/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.