linux-kernel - Re: [PATCH] x86: honor ACPI FADT flag indicating absence of a CMOS RTC

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, 18 Oct 2013 12:59:23 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	mingo@...e.hu, John Stultz <john.stultz@...aro.org>,
	tglx@...utronix.de, linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [PATCH] x86: honor ACPI FADT flag indicating absence of a CMOS
 RTC


* Jan Beulich <JBeulich@...e.com> wrote:

> >>> On 18.10.13 at 08:29, Ingo Molnar <mingo@...nel.org> wrote:
> > * Jan Beulich <JBeulich@...e.com> wrote:
> > 
> >> We shouldn't be creating a corresponding platform device in that case.
> > 
> > There's a sad lack of context in the changelog, how was it found, does 
> > this address any problem/bug observed in practice, etc?
> 
> This was a result from code review in Xen hypervisor code in the context 
> of ACPI 5 work there, which lead me to check whether Linux would honor 
> that flag. No known issue in practice so far. Once the below got 
> clarified, I can certainly extend the description in an eventual 
> resubmission (albeit I would have though that fixing the not honoring of 
> a firmware flag should speak for itself).

I thought we've been through this before, firmware related changes never 
'speak for themselves'!

The quality and effect of firmware flags varies wildly (sometimes they are 
good and avoid problems, sometimes they are crap and cause problems) and 
it's important to know the full context.

So in this area there's no such thing as being overly verbose in a 
changelog.

> >> +#ifdef CONFIG_ACPI
> >> +	if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
> >> +		return -ENODEV;
> >> +#endif
> > 
> > It might also be prudent to emit a KERN_INFO line telling that we don't 
> > create the device - so that people who suddenly see unexpected breakage or 
> > change in behavior have a chance to see what we've done?
> 
> There are so many other -ENODEV return paths here which don't
> emit messages that this seemed inappropriate, the more that a
> message _is_ being issued if the platform RTC device does get
> registered (and hence one could judge by the message
> disappearing between before and after the patch got applied).

I'm trying to be conservative and protect users against potential bad side 
effects of such a change. It's routine. We can mark it as temporary and 
zap it a few kernel releases later.

Thanks,

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