From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935033AbdCXKgh (ORCPT ); Fri, 24 Mar 2017 06:36:37 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33634 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbdCXKga (ORCPT ); Fri, 24 Mar 2017 06:36:30 -0400 Date: Fri, 24 Mar 2017 11:36:24 +0100 From: Ingo Molnar To: Ard Biesheuvel Cc: Dave Young , Baoquan He , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , "linux-efi@vger.kernel.org" , Thomas Garnier , Kees Cook , Borislav Petkov , Andrew Morton , Masahiro Yamada , Bhupesh Sharma Subject: Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization Message-ID: <20170324103624.GA6231@gmail.com> References: <1490331592-31860-1-git-send-email-bhe@redhat.com> <20170324080833.GA15200@gmail.com> <20170324083451.GC30442@x1> <20170324084609.GA6807@dhcp-128-65.nay.redhat.com> <20170324092433.GA3237@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Ard Biesheuvel wrote: > No. It is the firmware's EFI code, and the virtual translation applied by the OS > is made known to the firmware by means of a call into the runtime service > SetVirtualAddressMap(). This service can only be called once after each boot, > and so kexec kernels are forced to use the same VA mapping for runtime services > as the first kernel. This is the whole point of having a VA region reserved for > this, so that kexec kernels are guaranteed to be able to use the same VA > mapping. Yes, but it's the kernel's EFI code that determines the area! So my suggestion: > > Preserving virtual addresses for kexec is a red herring: the randomized offset > > could be passed to the kexec-ed kernel just fine. Would solve the kexec problem, right? I.e. the first kernel that boots randomizes the address range - and passes that offset off to any subsequent kernels. Turning KASLR off actively degrades that randomization of the kernel virtual addresses. Am I missing anything? Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization Date: Fri, 24 Mar 2017 11:36:24 +0100 Message-ID: <20170324103624.GA6231@gmail.com> References: <1490331592-31860-1-git-send-email-bhe@redhat.com> <20170324080833.GA15200@gmail.com> <20170324083451.GC30442@x1> <20170324084609.GA6807@dhcp-128-65.nay.redhat.com> <20170324092433.GA3237@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ard Biesheuvel Cc: Dave Young , Baoquan He , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thomas Garnier , Kees Cook , Borislav Petkov , Andrew Morton , Masahiro Yamada , Bhupesh Sharma List-Id: linux-efi@vger.kernel.org * Ard Biesheuvel wrote: > No. It is the firmware's EFI code, and the virtual translation applied by the OS > is made known to the firmware by means of a call into the runtime service > SetVirtualAddressMap(). This service can only be called once after each boot, > and so kexec kernels are forced to use the same VA mapping for runtime services > as the first kernel. This is the whole point of having a VA region reserved for > this, so that kexec kernels are guaranteed to be able to use the same VA > mapping. Yes, but it's the kernel's EFI code that determines the area! So my suggestion: > > Preserving virtual addresses for kexec is a red herring: the randomized offset > > could be passed to the kexec-ed kernel just fine. Would solve the kexec problem, right? I.e. the first kernel that boots randomizes the address range - and passes that offset off to any subsequent kernels. Turning KASLR off actively degrades that randomization of the kernel virtual addresses. Am I missing anything? Thanks, Ingo