lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 17 Mar 2013 08:36:57 -0600
From:	Myron Stowe <mstowe@...hat.com>
To:	Kay Sievers <kay@...y.org>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Myron Stowe <myron.stowe@...hat.com>,
	linux-hotplug@...r.kernel.org, linux-pci@...r.kernel.org,
	yuxiangl@...vell.com, yxlraid@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files

On Sun, 2013-03-17 at 15:29 +0100, Kay Sievers wrote:
> On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe <mstowe@...hat.com> wrote:
> > On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
> >> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
> >> <alex.williamson@...hat.com> wrote:
> >> > I'm assuming that the device only breaks because udevadm is dumping the
> >> > full I/O port register space of the device and that if an actual driver
> >> > was interacting with it through this interface that it would work.  Who
> >> > knows how many devices will have read side-effects by udevadm blindly
> >> > dumping these files.  Thanks,
> >>
> >> Sysfs is a too public interface to export things there which make
> >> devices/driver choke on a simple read() of an attribute.
> >>
> >> This is nothing specific to udevadm, any tool can do that. Udevadm
> >> will never read any of the files during normal operation. The admin
> >> explicitly asked udevadm with a specific command to dump all the stuff
> >> the device offers.
> >>
> >> The kernel driver needs to be fixed to allow that, in the worst case,
> >> the attributes not exported at all. People should take more care what
> >> they export in /sys, it's not a hidden and private ioctl what's
> >> exported there, stuff is very visible and will be looked at.
> >>
> >> Telling userspace not to use specific stuff in /sys I would not expect
> >> to work as a strategy; there is too much weird stuff out there that
> >> will always try to do that ...
> >
> > Kay - could you comment on Foot Note 3 in
> > https://lkml.org/lkml/2013/3/16/168
> >
> > With respect to 'udev', you are working on the assumption that all files
> > in sysfs must be readable with no consequences which may be implied by
> > the Documentation's sysfs.txt file's mentioning ASCII.  If we are to
> > interpret that as strictly as you seem to want to then why is there
> > sysfs support for creating binary files?
> 
> They cannot be distinguished from outside, so there is nothing I know
> that could make a difference to userspace tools.

Agreed
> 
> Tools -- no matter how useful they are not not, it's that they do that
> for many years already -- need to be able to read() the stuff in
> there, without causing any damage to the system.

So then, why are certain sysfs files skipped in udevadm-info's parsing
(./src/udevadm-info.c::skip_attribute())?
> 
> Kay


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ