| 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
| ||
|
Date: Tue, 24 Sep 2013 10:52:09 +0800 From: Dave Young <dyoung@...hat.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...e.de>, Matt Fleming <matt@...sole-pimps.org>, Matthew Garrett <mjg59@...f.ucam.org>, James Bottomley <James.Bottomley@...senPartnership.com>, Vivek Goyal <vgoyal@...hat.com>, linux-efi@...r.kernel.org Subject: Re: [PATCH -v2] EFI: Runtime services virtual mapping On 09/22/13 at 08:27am, H. Peter Anvin wrote: > The address that faults is interesting in that it is indeed just below -4G. The question at hand is probably what information you are using to build the EFI mappings in the secondary kernel and what could make it not match the primary. > > Assuming it isn't as simple as the mappings never get built at all. Here is my debug output, diff efi-mapping-1st-kernel efi-mapping-2nd-kernel: Obviously, the high address mapping is not same: --- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800 +++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800 @@ -1,30 +1,30 @@ efi mapping PA 0x800000 -> VA 0x800000 efi mapping PA 0x800000 -> VA 0xffffffff00000000 efi mapping PA 0x7c000000 -> VA 0x7c000000 -efi mapping PA 0x7c000000 -> VA 0xfffffffefffe0000 +efi mapping PA 0x7c000000 -> VA 0xffffffff00000000 efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000 -efi mapping PA 0x7d5e2000 -> VA 0xfffffffefffdf000 +efi mapping PA 0x7d5e2000 -> VA 0xfffffffefffff000 efi mapping PA 0x7d77d000 -> VA 0x7d77d000 -efi mapping PA 0x7d77d000 -> VA 0xfffffffefffde000 +efi mapping PA 0x7d77d000 -> VA 0xfffffffeffffe000 efi mapping PA 0x7d864000 -> VA 0x7d864000 -efi mapping PA 0x7d864000 -> VA 0xfffffffeff8d4000 +efi mapping PA 0x7d864000 -> VA 0xfffffffeff8f4000 efi mapping PA 0x7df6e000 -> VA 0x7df6e000 -efi mapping PA 0x7df6e000 -> VA 0xfffffffeff6ae000 +efi mapping PA 0x7df6e000 -> VA 0xfffffffeff6ce000 efi mapping PA 0x7e194000 -> VA 0x7e194000 -efi mapping PA 0x7e194000 -> VA 0xfffffffeff6ac000 +efi mapping PA 0x7e194000 -> VA 0xfffffffeff6cc000 efi mapping PA 0x7e196000 -> VA 0x7e196000 -efi mapping PA 0x7e196000 -> VA 0xfffffffeff696000 +efi mapping PA 0x7e196000 -> VA 0xfffffffeff6b6000 efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000 -efi mapping PA 0x7e1ac000 -> VA 0xfffffffeff681000 +efi mapping PA 0x7e1ac000 -> VA 0xfffffffeff6a1000 efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000 -efi mapping PA 0x7e1c1000 -> VA 0xfffffffefe041000 +efi mapping PA 0x7e1c1000 -> VA 0xfffffffefe061000 efi mapping PA 0x7f802000 -> VA 0x7f802000 -efi mapping PA 0x7f802000 -> VA 0xfffffffefdec2000 +efi mapping PA 0x7f802000 -> VA 0xfffffffefdee2000 efi mapping PA 0x7f981000 -> VA 0x7f981000 -efi mapping PA 0x7f981000 -> VA 0xfffffffefde92000 +efi mapping PA 0x7f981000 -> VA 0xfffffffefdeb2000 efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000 -efi mapping PA 0x7f9b1000 -> VA 0xfffffffefde6e000 +efi mapping PA 0x7f9b1000 -> VA 0xfffffffefde8e000 efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000 -efi mapping PA 0x7f9e5000 -> VA 0xfffffffefd873000 +efi mapping PA 0x7f9e5000 -> VA 0xfffffffefd893000 efi mapping PA 0x7ffe0000 -> VA 0x7ffe0000 -efi mapping PA 0x7ffe0000 -> VA 0xfffffffefd853000 +efi mapping PA 0x7ffe0000 -> VA 0xfffffffefd873000 > > > Borislav Petkov <bp@...en8.de> wrote: > >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: > >> I tested your new patch, it works both with efi stub and grub boot in > >> 1st kernel. > > > >Good, thanks! > > > >> But it paniced in kexec boot with my kexec related patcheset, the > >patchset > > > >That's the second kernel, right? > > > >> contains 3 patch: > >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump > >> 2. export physical addr fw_vendor, runtime, tables to > >/sys/firmware/efi/systab > >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; > >Also do not > >> call SetVirtualAddressMao in case kexecboot. > >> > >> The panic happens at the last line of efi_init: > >> /* clean DUMMY object */ > >> efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID, > >> EFI_VARIABLE_NON_VOLATILE | > >> EFI_VARIABLE_BOOTSERVICE_ACCESS | > >> EFI_VARIABLE_RUNTIME_ACCESS, > >> 0, NULL); > >> > >> Below is the dmesg: > >> [ 0.003359] pid_max: default: 32768 minimum: 301 > >> [ 0.004792] BUG: unable to handle kernel paging request at > >fffffffefde97e70 > >> [ 0.006666] IP: [<ffffffff8103a1db>] > >virt_efi_set_variable+0x40/0x54 > >> [ 0.006666] PGD 36981067 PUD 35828063 PMD 0 > > > >Here it is - fffffffefde97e70 is not mapped in the pagetable, PMD is 0. > > > >Ok, can you upload your patches somewhere and tell me exactly how to > >reproduce this so that I can take a look too? > > > >Thanks. > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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