| 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
| ||
|
Message-ID: <20130924045818.GC5561@dhcp-16-126.nay.redhat.com>
Date: Tue, 24 Sep 2013 12:58:19 +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/24/13 at 12:57pm, Dave Young wrote:
> On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> > Okay... I see two problems.
> >
> > 1. It looks like we subtract the region size after, rather than before, assigning an address.
> >
> > 2. The second region is assigned the same address in the secondary kernel as in the first, implying the size of the first region was somehow set to zero.
>
> I find the reason, efi_reserve_boot_services will reserve the BOOT_SERVICE_DATA region
> thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping addr after
> the md will be not same as 1st kernel, see below code:
>
> void __init efi_map_region(efi_memory_desc_t *md)
> {
> unsigned long size = md->num_pages << PAGE_SHIFT;
>
> efi_va -= size;
> ^^^^^^^^^^^^^^^
> [snip]
> }
So how about just reserve BOOT_SERVICE_DATA region but keep the md.numpages as is?
>
>
> >
> > Dave Young <dyoung@...hat.com> wrote:
> > >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.
> >
> > --
> > 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