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: <20151229124413.GB2467@eudyptula.hq.kempniu.pl>
Date:	Tue, 29 Dec 2015 13:44:13 +0100
From:	Michał Kępień <kernel@...pniu.pl>
To:	Pali Rohár <pali.rohar@...il.com>
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

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

-- 
Best regards,
Michał Kępień
--
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