All of lore.kernel.org
 help / color / mirror / Atom feed
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 08:05:16 +1100	[thread overview]
Message-ID: <1203368716.6740.24.camel@pasglop> (raw)
In-Reply-To: <20080218215842.66bb004f@hyperion.delvare>


> 
> * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
> 
> * Legacy PC hardware monitoring chips at 0x290-0x297.
> 
> * IPMI interface at 0x0ca3 and 0x0cab (read-only).
> 
> Please tell me which ones should be skipped on PowerPC.

Skip the whole thing. I consider that on a powerpc linux port, the
platform is responsible for telling drivers where things are (via the
device tree generally)
 
> Christian, can you tell me which of these probes caused trouble for you?
> 
> > > 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 :-)
> 
> The same could be done for user-space (or at the /dev/port level.)

Well, there are -other- legit usages of /dev/port...

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 08:05:16 +1100	[thread overview]
Message-ID: <1203368716.6740.24.camel@pasglop> (raw)
In-Reply-To: <20080218215842.66bb004f@hyperion.delvare>


> 
> * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
> 
> * Legacy PC hardware monitoring chips at 0x290-0x297.
> 
> * IPMI interface at 0x0ca3 and 0x0cab (read-only).
> 
> Please tell me which ones should be skipped on PowerPC.

Skip the whole thing. I consider that on a powerpc linux port, the
platform is responsible for telling drivers where things are (via the
device tree generally)
 
> Christian, can you tell me which of these probes caused trouble for you?
> 
> > > 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 :-)
> 
> The same could be done for user-space (or at the /dev/port level.)

Well, there are -other- legit usages of /dev/port...

Ben.



  parent reply	other threads:[~2008-02-18 21:06 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
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 [this message]
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=1203368716.6740.24.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.