linux-kernel - Re: [PATCH 1/2] dell-wmi: Check if Dell WMI descriptor structure is valid

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:	Tue, 29 Dec 2015 17:05:43 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Michał Kępień <kernel@...pniu.pl>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Darren Hart <dvhart@...radead.org>,
	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Andy Lutomirski <luto@...nel.org>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dell-wmi: Check if Dell WMI descriptor structure is valid

On Tuesday 29 December 2015 13:44:13 Michał Kępień wrote:
> > > > According to Dell WMI document mentioned in ML dicussion
> > > > archived at
> > > > http://www.spinics.net/lists/platform-driver-x86/msg07220.html
> > > > OS should check Dell WMI descriptor structure.
> > > 
> > > "Should" or "can"?  I skimmed through the ACPI-WMI PDF and
> > > Mario's message again and I couldn't find any explicit statement
> > > urging the reader to check the structure in question before
> > > doing anything else.
> > 
> > That's questionable... In "Design flow" is first point that WMI
> > descriptor check.
> 
> Which "Design flow" are you referring to?  Because I found at least
> two: chapter 2.3 and a subsection of chapter 2.3.3.  Funnily enough,
> in both of these locations the WMI Descriptor Method is discussed
> first.
> 
> Personally, I wouldn't use the structure of that document to draw
> cause-effect conclusions.  Just look at the last chapter (2.3.4),
> which shows how to tell whether the BIOS supports the ACPI-WMI
> interface. Shouldn't that be the first thing to check, before doing
> anything else mentioned in that document?  Yet, it's the last thing
> discussed.
> 
> Anyway, while the document mentions in several places that the BIOS
> WMI Descriptor object can be queried, it fails to convince me as to
> why this is necessary at all as all values in the returned buffer
> are constant. Perhaps parsing the buffer is useful as a sanity check
> of some kind, but it certainly isn't a prerequisite for performing
> further actions.
> 
> Given the nature of your patchset, I'd personally rephrase the commit
> message(s) to state that according to your observations, there are
> behavioral differences between models with different versions of the
> WMI Interface, so we parse the WMI Descriptor object to determine
> which WMI Interface version is used on the machine we're running on.
>  Perhaps with an additional word or two that it won't hurt to also
> check the WMI Descriptor object's correctness while we're at it.
> 
> If you feel like I'm nit-picking and none of the above matters,
> please feel free to disregard my input and just follow your gut.

It's ok. We just understand it quite differently. And in this case what 
about changing commit message to something like this?

===
dell-wmi: Check if Dell WMI descriptor structure is valid

After examining existing DSDT ACPI tables of more laptops and looking 
into Dell WMI document mentioned in ML dicussion archived at 
http://www.spinics.net/lists/platform-driver-x86/msg07220.html we will 
parse and check WMI descriptor if contains expected data. It is because 
WMI descriptor contains interface version number and it is needed to 
know in next commit.
===

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)