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

>>> On 07.08.12 at 05:06, JérômeCarretero <cJ-ko@...gloub.eu> wrote:
> On Mon, 6 Aug 2012 22:32:08 -0400
> Jérôme Carretero <cJ-ko@...gloub.eu> wrote:
> 
>> For troubleshooting purposes I edited over your patch.
>> So far:
>> [...]
>> Maybe I can get more...
> 
> With the following:
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 2dc29f5..46729f3 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -97,8 +97,9 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, 
> efi_time_cap_t *tc)
>         unsigned long flags;
>         efi_status_t status;
>  
> +       printk("%s: get_time=0x%p\n", __func__, 
> efi.systab->runtime->get_time);
>         spin_lock_irqsave(&rtc_lock, flags);
> -       status = efi_call_virt2(get_time, tm, tc);
> +       status = EFI_SUCCESS + 1;// efi_call_virt2(get_time, tm, tc);
>         spin_unlock_irqrestore(&rtc_lock, flags);
>         return status;
>  }
> @@ -270,8 +271,10 @@ static unsigned long efi_get_time(void)
>         efi_time_cap_t cap;
>  
>         status = efi.get_time(&eft, &cap);
> -       if (status != EFI_SUCCESS)
> -               pr_err("Oops: efitime: can't read time!\n");
> +       if (status != EFI_SUCCESS) {
> +               /* fall back to RTC time */
> +               return mach_get_cmos_time();
> +       }
>  
>         return mktime(eft.year, eft.month, eft.day, eft.hour,
>                       eft.minute, eft.second);
> 
> The system boots, at that point...

That's not surprising. The question really is what goes wrong
when the call is being made - page fault, some other fault, or
silent hang. A page fault would point to an incorrect memory
map as the prime candidate for causing the problem. My
primary suspect would be #NM, i.e. the implementation using
floating point (SSE to be precise) instructions when they're
unavailable.

> I would say my BIOS is broken,
> but it can be expected that others can have the same issue.

Likely. The question is whether we could make Linux be spec
compliant on sane systems _and_ tolerate broken ones like
this. But whether e.g. adding a command line option (or DMI-
based quirk) is appropriate depends on whether this really is
a firmware issue or a flaw in the patch.

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/