linux-kernel - Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

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:	Fri, 20 Dec 2013 11:53:10 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	joeyli <jlee@...e.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Matt Fleming <matt@...sole-pimps.org>,
	Matthew Garrett <matthew.garrett@...ula.com>, Elliott@...com,
	samer.el-haj-mahmoud@...com, Oliver Neukum <oneukum@...e.de>,
	werner@...e.com, JBeulich@...e.com, linux-kernel@...r.kernel.org,
	rtc-linux@...glegroups.com, x86@...nel.org,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Borislav Petkov <bp@...e.de>
Subject: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
> 
> According to the Microsoft requirements documents, such a platform is
> broken and shouldn't exist.

Is this a public document?
Probably not but if, a pointer in this thread would help.
Does Microsoft mention ACPI Time and Alarm Device interface in
such a document already?

I expect that future platforms will make more and more use of the
ACPI/EFI specified time functions.

It's probably up to Microsoft requiring this at some point of time,
then this stuff will work reliable, possibly others will not anymore.

Given the fact that there are machines which implement this interface
already and it is likely that more and more will, IMHO a first
implementation of this stuff in the kernel, even there are broken BIOSes
around, makes *a lot of* sense.

I suggest a whitelist, however it looks like:
  -> platforms which do not have a PNP0B0x device?
  -> dmi whitelist working platforms
  -> Extend it later with conditions where we know things work as expected

best also introduce an acpi=enable/disable_tad (or simlar) boot param which 
overrides white/blacklisting.
This will allow users to make use of this which may otherwise run into
problems and it will also allow easier testing and feedback
how reliable latest BIOS implementations are.

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