From: Dave Young <dyoung@redhat.com> To: Baoquan He <bhe@redhat.com> Cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, linux-efi@vger.kernel.org, Thomas Garnier <thgarnie@google.com>, Kees Cook <keescook@chromium.org>, Borislav Petkov <bp@alien8.de>, Andrew Morton <akpm@linux-foundation.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, Bhupesh Sharma <bhsharma@redhat.com> Subject: Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization Date: Fri, 24 Mar 2017 16:46:09 +0800 [thread overview] Message-ID: <20170324084609.GA6807@dhcp-128-65.nay.redhat.com> (raw) In-Reply-To: <20170324083451.GC30442@x1> On 03/24/17 at 04:34pm, Baoquan He wrote: > On 03/24/17 at 09:08am, Ingo Molnar wrote: > > > Cc: <stable@vger.kernel.org> #4.8+ > > > Signed-off-by: Baoquan He <bhe@redhat.com> > > > Acked-by: Dave Young <dyoung@redhat.com> > > > Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> > > > Acked-by: Thomas Garnier <thgarnie@google.com> > > > Cc: Thomas Gleixner <tglx@linutronix.de> > > > Cc: Ingo Molnar <mingo@redhat.com> > > > Cc: "H. Peter Anvin" <hpa@zytor.com> > > > Cc: x86@kernel.org > > > Cc: linux-efi@vger.kernel.org > > > Cc: Thomas Garnier <thgarnie@google.com> > > > Cc: Kees Cook <keescook@chromium.org> > > > Cc: Borislav Petkov <bp@alien8.de> > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > > > Cc: Dave Young <dyoung@redhat.com> > > > Cc: Bhupesh Sharma <bhsharma@redhat.com> > > > > So I applied this kexec fix and extended the changelog to clearly show why this > > fix matters in practice. > > I thought it only impacts kexec, but Dave thought it will impact 1st > kenrel either. Yes, I think no need to mention kexec, it is a general issue. First, the space is reserved for EFI, so kernel should not use it for kaslr. Second, EFI page tables sync the low kernel page tables into its own page tables, if others use this space for non-EFI then those part will be missing. arch/x86/platform/efi/efi_64.c efi_sync_low_kernel_mappings() is syncing kernel page tables to efi's. >From the function comment below: Add low kernel mappings for passing arguments to EFI functions. Suppose some arguments use kaslr randomized address which is within efi ranges then we will hit bugs. But we do not see actual bug reports in real world yet. This is found during patch review. Anyway, since this area is EFI reserved, no reason to add it to kaslr pool. > > > > Also, to make sure I understood it correctly: these addresses are all dynamic on > > 64-bit kernels, i.e. we are establishing and then tearing down these page tables > > around EFI calls, and they are 'normally' not present at all, right? > > The EFI region is reserved for EFI runtime services virtual mapping, the > original purpose is to preserve this region so that they can be reused > by kexec-ed kernel. This was introduced by Boris in commit d2f7cbe7b26a7 > ("x86/efi: Runtime services virtual mapping"). > > So it will be establishing and stay there. According to Dave's telling, > efi will still fetch efi variables or time/date by runtime service by > switching the efi pgd and entering into efi mode. And then switch back > to normal OS. Not sure if I am right for efi part in 1st kernel. For 2nd > kernel, if want to reuse the them, the efi region has to be kept. > > Thanks > Baoquan Thanks Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Thomas Garnier <thgarnie-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>, Bhupesh Sharma <bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Subject: Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization Date: Fri, 24 Mar 2017 16:46:09 +0800 [thread overview] Message-ID: <20170324084609.GA6807@dhcp-128-65.nay.redhat.com> (raw) In-Reply-To: <20170324083451.GC30442@x1> On 03/24/17 at 04:34pm, Baoquan He wrote: > On 03/24/17 at 09:08am, Ingo Molnar wrote: > > > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> #4.8+ > > > Signed-off-by: Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > Acked-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > Reviewed-by: Bhupesh Sharma <bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > Acked-by: Thomas Garnier <thgarnie-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> > > > Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > > > Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > Cc: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> > > > Cc: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > > > Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > > Cc: Thomas Garnier <thgarnie-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> > > > Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > > > Cc: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org> > > > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > > > Cc: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> > > > Cc: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > Cc: Bhupesh Sharma <bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > So I applied this kexec fix and extended the changelog to clearly show why this > > fix matters in practice. > > I thought it only impacts kexec, but Dave thought it will impact 1st > kenrel either. Yes, I think no need to mention kexec, it is a general issue. First, the space is reserved for EFI, so kernel should not use it for kaslr. Second, EFI page tables sync the low kernel page tables into its own page tables, if others use this space for non-EFI then those part will be missing. arch/x86/platform/efi/efi_64.c efi_sync_low_kernel_mappings() is syncing kernel page tables to efi's. >From the function comment below: Add low kernel mappings for passing arguments to EFI functions. Suppose some arguments use kaslr randomized address which is within efi ranges then we will hit bugs. But we do not see actual bug reports in real world yet. This is found during patch review. Anyway, since this area is EFI reserved, no reason to add it to kaslr pool. > > > > Also, to make sure I understood it correctly: these addresses are all dynamic on > > 64-bit kernels, i.e. we are establishing and then tearing down these page tables > > around EFI calls, and they are 'normally' not present at all, right? > > The EFI region is reserved for EFI runtime services virtual mapping, the > original purpose is to preserve this region so that they can be reused > by kexec-ed kernel. This was introduced by Boris in commit d2f7cbe7b26a7 > ("x86/efi: Runtime services virtual mapping"). > > So it will be establishing and stay there. According to Dave's telling, > efi will still fetch efi variables or time/date by runtime service by > switching the efi pgd and entering into efi mode. And then switch back > to normal OS. Not sure if I am right for efi part in 1st kernel. For 2nd > kernel, if want to reuse the them, the efi region has to be kept. > > Thanks > Baoquan Thanks Dave
next prev parent reply other threads:[~2017-03-24 8:46 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-24 4:59 [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization Baoquan He 2017-03-24 4:59 ` Baoquan He 2017-03-24 8:08 ` Ingo Molnar 2017-03-24 8:08 ` Ingo Molnar 2017-03-24 8:34 ` Baoquan He 2017-03-24 8:34 ` Baoquan He 2017-03-24 8:46 ` Dave Young [this message] 2017-03-24 8:46 ` Dave Young 2017-03-24 9:24 ` Ingo Molnar 2017-03-24 9:36 ` Borislav Petkov 2017-03-24 9:37 ` Ard Biesheuvel 2017-03-24 9:37 ` Ard Biesheuvel 2017-03-24 9:40 ` Borislav Petkov 2017-03-24 9:42 ` Ard Biesheuvel 2017-03-24 9:46 ` Borislav Petkov 2017-03-24 9:46 ` Borislav Petkov 2017-03-24 9:52 ` Ard Biesheuvel 2017-03-24 9:52 ` Ard Biesheuvel 2017-03-24 10:36 ` Ingo Molnar 2017-03-24 10:36 ` Ingo Molnar 2017-03-24 10:42 ` Ard Biesheuvel 2017-03-24 10:54 ` Ingo Molnar 2017-03-24 11:52 ` Baoquan He 2017-03-24 8:53 ` Dave Young 2017-03-24 8:10 ` [tip:x86/urgent] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization tip-bot for Baoquan He
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170324084609.GA6807@dhcp-128-65.nay.redhat.com \ --to=dyoung@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=bhsharma@redhat.com \ --cc=bp@alien8.de \ --cc=hpa@zytor.com \ --cc=keescook@chromium.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=stable@vger.kernel.org \ --cc=tglx@linutronix.de \ --cc=thgarnie@google.com \ --cc=x86@kernel.org \ --cc=yamada.masahiro@socionext.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.