linux-kernel - Re: [PATCH] ACPI: Adjust the return value of

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]

Message-ID: <3241492.O6brgYIrX9@vostro.rjw.lan>
Date:	Tue, 24 Mar 2015 21:02:33 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	Mario Limonciello <mario_limonciello@...l.com>,
	Jason Ekstrand <jason@...kstrand.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Bard Liao <bardliao@...ltek.com>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	linux-acpi@...r.kernel.org, lenb@...nel.org
Subject: Re: [PATCH] ACPI: Adjust the return value of _REV on x86

On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
> On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
> >
> > Aside from the mistake that was made in A01 ( which has been corrected
> > for the recently released A02 ), the goal of this workaround is to be
> > able to provide a more functional audio solution across a wider
> > user-base.  Supporting HDA audio for Linux means that users from older
> > kernels will still have a mostly working solution and not need to wait
> > for the entire set of I2S kernel and userspace patches to land in
> > their distro of choice.  We can't expect everyone to run the latest
> > kernel just to have working audio.
> 
> Running a recent kernel is the tradeoff to be paid for using brand new
> hardware. I certainly don't expect to be able to install a 4-year old
> version of Fedora on a laptop released this year and have it work
> flawlessly.
> 
> Besides, distributions aggressively backport patches for new hardware
> support anyway and you should work with the distribution developers to
> ensure that happens for your hardware. Preferably before it gets
> released.
> 
> Because, fundamentally, when you make these decisions about Linux in the
> BIOS you're pitting the BIOS and kernel development models against each
> other. What is going to happen when i2s/i2c finally works correctly in
> the kernel and distros? It would seem unlikely that a BIOS update would
> be available to switch everyone to that mode.
> 
> > The entire I2S experience is maturing (thanks Bard), but even in
> > 4.0-rc5 there are still gaps.
> 
> I'm sure the audio folks would love to hear about them.
> 
> > >Non-Windows BIOS code paths are not validated to the same degree as
> > >those traversed by running Windows, which is exactly why we try so hard
> > >to emulate Windows whenever we interact with the BIOS.
> >
> > To be clear - this codepath is activating the Windows 7 audio
> > experience even when Windows 8.1 is detected (Windows 2013 _OSI
> > responds True).  It's still a Windows BIOS codepath and it's still
> > heavily validated.  There are 3 values you'll find in a decompiled
> > DSDT to achieve this in the _REV test block.  2 of them are used to
> > provide inputs into the EC to toggle HDA or I2S mode.  The other
> > modifies what ACPI audio device is presented to the system.  There
> > isn't a special OS type to represent Linux here.  The selected OSTP
> > corresponds to the Windows 7 OS type.
>  
> Thanks, that is clearer and it does address my concerns about Linux-only
> code paths in the BIOS. But the use of _REV is still only exists to
> detect Linux (or more accurately an ACPICA OS), and that's a big issue.
> 
> > In any case, if the _REV patch does land in the kernel, I think (we)
> > Dell will still be mostly happy with the results.  Anything older than
> > 4.x won't contain the the _REV patch and will run in HDA mode.
> 
> Unless the patch gets backported to stable kernel versions older than
> 4.x. Which is likely.

While I agree in general, one comment.

We haven't decided about the patch yet.  We may decide to bump up the _REV
to 6 when ACPI 6 is out instead.

That said the whole using of _REV to special case Linux is broken by design
and should be stopped immediately.  Especially when it is done by comparing
the return value of _REV to a specific number (like 5 or 3).

Rafael

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