From: Greg KH <gregkh@linuxfoundation.org>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Myron Stowe <mstowe@redhat.com>,
Myron Stowe <myron.stowe@redhat.com>,
kay@vrfy.org, linux-hotplug@vger.kernel.org,
alex.williamson@redhat.com, linux-pci@vger.kernel.org,
yuxiangl@marvell.com, yxlraid@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
Date: Mon, 18 Mar 2013 19:35:25 -0700 [thread overview]
Message-ID: <20130319023525.GA21789@kroah.com> (raw)
In-Reply-To: <CADLC3L2hKYPsW4fvg6tbptBc1r7LS=7Ndwhp4mZ3BKzJq6z-eg@mail.gmail.com>
On Mon, Mar 18, 2013 at 08:09:22PM -0600, Robert Hancock wrote:
> > Great, that's one possible solution, the other is just not creating the
> > files at all for known problem devices, right?
>
> I don't think one can reasonably enumerate all problem devices. There
> are probably countless devices which can potentially break if their
> resources (especially IO ports) are read in unexpected ways. Aside
> from devices like this one, which apparently don't like certain IO
> ports being read with certain access widths, there's every device in
> existence with read-to-reset type registers. The fix to this needs to
> apply to all devices.
>
> >
> > My main point here is, you aren't going to fix this in userspace, fix it
> > in the kernel.
>
> The kernel can help the situation by blocking access to devices with
> an active driver, but it can't fix all cases. Suppose the device has
> no driver loaded yet, how is the kernel supposed to tell the
> difference between software with a legitimate need to access these
> files for virtualization device assignment, etc. and something like
> udevadm or a random grep command that's reading the files without any
> idea what it's doing? udevadm does need to be fixed to avoid accessing
> these files because it's unnecessary and dangerous.
Are you going to also fix grep? bash? cat?
Come on, be realistic. If these files are so dangerous then they need
to just be removed entirely from the kernel. You aren't going to be
able to patch grep for this.
greg k-h
next prev parent reply other threads:[~2013-03-19 2:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-16 21:35 [PATCH] udevadm-info: Don't access sysfs entries backing device I/O port space Myron Stowe
2013-03-16 21:35 ` [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files Myron Stowe
2013-03-16 22:11 ` Greg KH
2013-03-16 22:55 ` Bjorn Helgaas
2013-03-16 23:50 ` Myron Stowe
2013-03-17 1:03 ` Greg KH
2013-03-17 4:11 ` Alex Williamson
2013-03-17 5:36 ` Greg KH
2013-03-17 13:38 ` Alex Williamson
2013-03-17 14:00 ` Kay Sievers
2013-03-17 14:20 ` Myron Stowe
2013-03-17 14:29 ` Kay Sievers
2013-03-17 14:36 ` Myron Stowe
2013-03-17 14:43 ` Kay Sievers
2013-03-18 16:24 ` Alex Williamson
2013-03-18 16:41 ` Greg KH
2013-03-18 16:51 ` Alex Williamson
2013-03-18 17:20 ` Bjørn Mork
2013-03-18 17:54 ` Alex Williamson
2013-03-18 18:02 ` Robert Brown
2013-03-18 18:25 ` Bjørn Mork
2013-03-18 18:59 ` Alex Williamson
2013-03-19 16:57 ` Myron Stowe
2013-03-19 17:06 ` Myron Stowe
2013-03-17 14:33 ` Myron Stowe
2013-03-17 22:28 ` Alex Williamson
2013-03-18 14:50 ` Don Dutile
2013-03-18 16:34 ` Alex Williamson
2013-03-17 14:12 ` Myron Stowe
2013-03-19 1:54 ` Robert Hancock
2013-03-19 2:03 ` Greg KH
2013-03-19 2:09 ` Robert Hancock
2013-03-19 2:35 ` Greg KH [this message]
2013-03-19 3:08 ` Robert Hancock
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=20130319023525.GA21789@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alex.williamson@redhat.com \
--cc=hancockrwd@gmail.com \
--cc=kay@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mstowe@redhat.com \
--cc=myron.stowe@redhat.com \
--cc=yuxiangl@marvell.com \
--cc=yxlraid@gmail.com \
/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