From: Greg KH <gregkh@linuxfoundation.org>
To: Myron Stowe <myron.stowe@redhat.com>
Cc: 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: Sat, 16 Mar 2013 15:11:59 -0700 [thread overview]
Message-ID: <20130316221159.GA3702@kroah.com> (raw)
In-Reply-To: <20130316213519.2974.38954.stgit@amt.stowe>
On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
> Port space and MMIO. This memory regions correspond to the device's
> internal status and control registers used to drive the device.
>
> Accessing these registers from userspace such as "udevadm info
> --attribute-walk --path=/sys/devices/..." does can not be allowed as
> such accesses outside of the driver, even just reading, can yield
> catastrophic consequences.
>
> Udevadm-info skips parsing a specific set of sysfs entries including
> 'resource'. This patch extends the set to include the additional
> 'resource<N>' entries that correspond to a PCI device's BARs.
Nice, are you also going to patch bash to prevent a user from reading
these sysfs files as well? :)
And pciutils?
You get my point here, right? The root user just asked to read all of
the data for this device, so why wouldn't you allow it? Just like
'lspci' does. Or bash does.
If this hardware has a problem, then it needs to be fixed in the kernel,
not have random band-aids added to various userspace programs to paper
over the root problem here. Please fix the kernel driver and all should
be fine. No need to change udevadm.
greg k-h
next prev parent reply other threads:[~2013-03-16 22:10 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 [this message]
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
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=20130316221159.GA3702@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alex.williamson@redhat.com \
--cc=kay@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--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