linux-kernel - Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

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: <501FDDD30200007800092DDE@nat28.tlf.novell.com>
Date:	Mon, 06 Aug 2012 14:08:03 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Matthew Garrett" <mjg59@...f.ucam.org>
Cc:	"Ingo Molnar" <mingo@...nel.org>,
	"Matt Fleming" <matt.fleming@...ux.intel.com>,
	<linux-efi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<cJ-ko@...gloub.eu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Regression] "x86-64/efi: Use EFI to deal with platform
 wall clock" prevents my machine from booting

>>> On 06.08.12 at 14:52, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Mon, Aug 06, 2012 at 07:44:34AM +0100, Jan Beulich wrote:
> 
>> In any case, without having seen _how_ things break I don't
>> think a decision should be taken if/how to address this
>> (apparent) regression.
> 
> Machines that previously worked no longer work. That's a pretty strong 
> argument in favour of reverting until we can identify a workaround.

Yes, one can view it that way. But then again things should have
been the way they are now from the beginning - it appears
rather questionable how someone would have come up with the
strange idea to stick some #ifdef CONFIG_X86_32 in there, and
not even bother to comment this hackery. Hence my position is
that this really very likely should have never worked on the box
in question, it was merely one bug hiding another. But of course
all this is guesswork without knowing the technical details of the
observed crash.

Plus I'm pretty convinced that once the change gets reverted,
the code will remain that way for another couple of years (and
quite likely whatever UEFI implementation it is that we have
the problem with here will too), as then there's no incentive for
anyone to get this done properly (until the then very sad day
where some EFI system shows up that, being legacy free,
_really_ doesn't have a CMOS RTC anymore - with the change
at hand I merely tried to be proactive).

Jan

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