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>] [day] [month] [year] [list]
Message-ID: <57584B822BA449119ABCE0A3C0B3B64A@thje6600v>
Date:	Mon, 23 Feb 2009 18:29:02 +0100
From:	"Thomas Jourdan" <tjourdan@...erfaceconcept.com>
To:	<linux-kernel@...r.kernel.org>
Subject: [BUG] efi_call_phys arguments has virtual address on IA32 / EFI

Hi

On a x86 UEFI (IA32) platform, with CONFIG_EFI enabled, I have the following
error on boot :
...
PID hash table entries: 4096 (order: 12, 16384 bytes)
Oops: efitime: can't read time!
TSC: PIT calibration matches PMTIMER. 1 loops
...

This happens early (during start_kernel), the first time we call the
efi_get_time function of EFI runtime services (from timekeeping_init). At
this moment, phys_efi_get_time is called. I'm not fluent with x86 assembler
but it seems that there is a bug in the efi_call_phys function
(arch/x86/kernel/efi_stub_32.S). From what I understand, we need to switch
from virtual mode to flat mode, ie removing __PAGE_OFFSET for the low
memory. It seems that it is not the case for the parameters.

For example, phys_efi_get_time uses 2 parameters : efi_time_t *tm and
efi_time_cap_t *tc. In my case, when phys_efi_get_time is called, tm =
0xC05C5FA8 (valid kernel virtual address). When I enter the associated get
time function of my efi firmware, the tm paramater has been put into %EDI,
which is 0xC05C5FA8, not 0x005C5FA8 :
- If I continue the execution of the get time function from the efi
firmware, rtc value are stored at invalid address and we leave the function
with an error.
- If I manually change the %EDI value from 0xC05C5FA8 to 0x005C5FA8 before
executing the get time function of the efi firmware, the function behaves
correctly, and there is no error.

Could someone confirm that it is really a bug ? If a patch is proposed, I
can test it quickly.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ