linux-kernel - Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

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:	Wed, 02 Jan 2013 07:26:32 +0000
From:	Matt Fleming <matt.fleming@...el.com>
To:	joeyli <jlee@...e.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Jan Beulich <JBeulich@...e.com>, Len Brown <lenb@...nel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled

On Wed, 2013-01-02 at 10:45 +0800, joeyli wrote:
> I didn't find the EFI RTC problem on Asus from google. 
> Could you please share what's the situation on ASUS hardware?

It's mentioned in the following commit (which has since been reverted in
Linus' tree),

commit 185034e72d591f9465e5e18f937ed642e7ea0070
Author: Matt Fleming <matt.fleming@...el.com>
Date:   Fri Sep 7 18:28:04 2012 +0100

    x86, efi: 1:1 pagetable mapping for virtual EFI calls
    
    Some firmware still needs a 1:1 (virt->phys) mapping even after we've
    called SetVirtualAddressMap(). So install the mapping alongside our
    existing kernel mapping whenever we make EFI calls in virtual mode.
    
    This bug was discovered on ASUS machines where the firmware
    implementation of GetTime() accesses the RTC device via physical
    addresses, even though that's bogus per the UEFI spec since we've
    informed the firmware via SetVirtualAddressMap() that the boottime
    memory map is no longer valid.
    
    This bug seems to be present in a lot of consumer devices, so there's
    not a lot we can do about this spec violation apart from workaround
    it.
    

The bug was originally mentioned here,

	https://lkml.org/lkml/2012/3/12/214


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