All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] sensors-detect: Skip "random" I/O port
Date: Fri, 22 Feb 2008 21:26:16 +0000	[thread overview]
Message-ID: <1203715576.6976.4.camel@pasglop> (raw)
In-Reply-To: <20080218223317.2142dc16@hyperion.delvare>


On Fri, 2008-02-22 at 08:44 +0100, Jean Delvare wrote:
> On Fri, 22 Feb 2008 18:21:23 +1100, Benjamin Herrenschmidt wrote:
> > 
> > On Fri, 2008-02-22 at 08:19 +0100, Jean Delvare wrote:
> > > 
> > > I was referring to the kernel patch Christian submitted earlier this
> > > week which prevents oopses or machine checks when older versions of
> > > sensors-detect access /dev/port in unexpected ways. My update to
> > > sensors-detect was meant as a complement of his patch, not a
> > > replacement.
> > 
> > But his patch can't recognize a potentially valid use of /proc/port
> > right ?
> 
> I don't know much about PPC so I can't comment on the implementation.
> All I'm saying is that, if it is possible at all, I believe that
> preventing invalid accesses from oopsing the machine is a good idea.

Preventing root from doing something stupid is not worth bothering.

I don't see how you can effectively prevent invalid accesses to
IO ports without also blocking potentially valid ones in that case,
unless the kernel happens to know exactly what is where (which isn't
necessarily the case as far as such IOs are concerned) and even
then, who can the kernel differenciate ?

For example, on some machines, I have seen firmwares putting PCI IO BARs
of device where usually legacy stuff is on x86. So while accesses to
this area via /proc would be legit by something that knows about that
device, something like sensors-detect would definitely do the wrong
thing by assuming those ports are hooked up to legacy devices.

Ben.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2008-02-22 21:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 21:33 [lm-sensors] [PATCH] sensors-detect: Skip "random" I/O port probing Jean Delvare
2008-02-18 22:46 ` [lm-sensors] [PATCH] sensors-detect: Skip "random" I/O port Benjamin Herrenschmidt
2008-02-20 19:07 ` Jean Delvare
2008-02-21 10:02 ` Christian Krafft
2008-02-21 10:09 ` Jean Delvare
2008-02-21 22:49 ` Benjamin Herrenschmidt
2008-02-22  7:19 ` Jean Delvare
2008-02-22  7:21 ` Benjamin Herrenschmidt
2008-02-22  7:44 ` Jean Delvare
2008-02-22 10:18 ` Christian Krafft
2008-02-22 21:26 ` Benjamin Herrenschmidt [this message]
2008-02-22 22:22 ` [lm-sensors] [PATCH] sensors-detect: Skip "random" I/O Benjamin Herrenschmidt

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=1203715576.6976.4.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=lm-sensors@vger.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 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.