All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Jackson <ajax@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/2] char/mem: Add /dev/io (v2)
Date: Tue, 07 Feb 2012 19:38:47 -0500	[thread overview]
Message-ID: <4F31C417.30502@redhat.com> (raw)
In-Reply-To: <20120208001724.7e5c7be4@pyramind.ukuu.org.uk>

On 2/7/12 7:17 PM, Alan Cox wrote:
> On Tue,  7 Feb 2012 18:39:45 -0500
> Adam Jackson<ajax@redhat.com>  wrote:
>
>> This is like /dev/port except not broken.  /dev/port will translate all
>> read/write into inb/outb streams, which is wrong since hardware can and
>> does care about cycle size.  /dev/io will only allow 1, 2, or 4 byte
>> access, and will translate that into the appropriate bus cycle size.
>
> From a security perspective /dev/[k][mem is a dumb bit of ancient Unix
> history we'd dearly like to kill off. /dev/port is a similar early PC
> unixism that wants to go the same way. /dev/io just adds another horror
> to the pile.
>
> Please do the decent thing, stop using /dev/mem and /dev/port for
> anything. If you need to access an I/O device make it properly visible
> via the kernel only for the ports and in a manner that is safe.

Yeah, I'll be sure to do that right as soon as I can stop supporting the 
vesa driver.  Until that time I don't really have any choice but to 
expose the whole of I/O port space, since I have no idea what the video 
BIOS is going to touch.

I don't disagree with wanting to limit access to these services, but 
/dev/io is at least somewhat containable, whereas iopl is insane.

- ajax


  reply	other threads:[~2012-02-08  0:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-07 14:11 [PATCH 1/2] char/mem: Add /dev/io Adam Jackson
2012-02-07 14:11 ` [PATCH 2/2] char/mem: Schedule /dev/port for removal Adam Jackson
2012-02-07 23:39 ` [PATCH 1/2] char/mem: Add /dev/io (v2) Adam Jackson
2012-02-08  0:17   ` Alan Cox
2012-02-08  0:38     ` Adam Jackson [this message]
2012-02-08  9:26       ` Alan Cox
2012-02-08 14:03         ` Adam Jackson
2012-02-08 14:32           ` Alan Cox
2012-02-08 23:16             ` Adam Jackson
2012-02-09 11:27               ` Alan Cox

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=4F31C417.30502@redhat.com \
    --to=ajax@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@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.