linux-kernel - Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

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] [day] [month] [year] [list]

Message-ID: <3406d772-4a5e-2cf8-a234-d3f3ff73a589@citrix.com>
Date:	Thu, 28 Jul 2016 01:03:33 +0100
From:	Andrew Cooper <andrew.cooper3@...rix.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Vrabel <dvrabel@...tab.net>,
	Shannon Zhao <shannon.zhao@...aro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 28/07/2016 00:46, Rafael J. Wysocki wrote:
> On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote:
>> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>> The STAO definition document:
>>>
>>> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
>>>
>>> requires as to "operate as if that device does not exist", quite literally.
>> Well, first off, documentation is one thing, actually changing
>> behavior is something entirely different.
>>
>> Theory and practice are *not* the same.
> Well, the STAO thing is totally new, so we have the documentation only ATM.
>
>> The other worry I have is that I'd be happier if it's still visible in
>> /sys/bus/acpi/ etc. Again, it's one thing to not react to it
>> programmatically, and another thing entirely to actually hide the
>> information from the rest of the system.
>>
>> If I read that patch right, it will be hidden from sysfs too. But
>> Maybe I'm mistaken.
> You're right.
>
> Avoiding to enumerate it entirely is somewhat simpler, because it allows
> us to avoid some special casing in a few places IIRC.
>
> I guess we can ask the author of the commit in question to come up with a
> patch to unhide that device and we'll see how that looks like.

Well - the entire purpose of STAO is to list system resources which are
genuinely in use by the hypervisor, and genuinely can't be mapped or
used by the kernel (these latter two frequently resulting in crashes or
hangs at early boot).

Identifying that such devices exist is reasonable (it is certainly
possibly by dumping the raw acpi tables), but any sysfs tweakable is
going to end in misery.

~Andrew