linux-kernel - Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files

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:	Mon, 18 Mar 2013 14:02:01 -0400
From:	Robert Brown <rj@...labs.com>
To:	Alex Williamson <alex.williamson@...hat.com>
CC:	Bjørn Mork <bjorn@...k.no>,
	Greg KH <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>, Myron Stowe <mstowe@...hat.com>,
	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 03/18/13 13:54, Alex Williamson wrote:
> On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
>> Alex Williamson <alex.williamson@...hat.com> writes:
>>
>>> At least for KVM the kernel fix is the addition of the vfio driver which
>>> gives us a non-sysfs way to do this.  If this problem was found a few
>>> years later and we were ready to make the switch I'd support just
>>> removing these resource files.  In the meantime we have userspace that
>>> depends on this interface, so I'm open to suggestions how to fix it.
>> I am puzzled by a couple of things in this discussion:
>>
>> 1) do you seriously mean that a userspace application (any, not just
>>    udevadm or qemu or whatever) should be able to read and write these
>>    registers while the device is owned by a driver?  How is that ever
>>    going to work?
> The expectation is that the user doesn't mess with the device through
> pci-sysfs while it's running.  This is really no different than config
> space or MMIO space in that respect.  You can use setpci to break your
> PCI card while it's used by the driver today.  The difference is that
> MMIO spaces side-step the issue by only allowing mmap and config space
> is known not to have read side-effects.
>
>> 2) is it really so that a device can be so fundamentally screwed up by
>>    reading some registers, that a later driver probe cannot properly
>>    reinitialize it?
> Never underestimate how broken hardware can be, though in this case
> reading a device register seems to be causing a system hang/reset.
The real problem is that PCI devices can be bus masters, which means
they can screw up *ANYTHING* (almost)!

--
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/