From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752794AbbCGVGg (ORCPT ); Sat, 7 Mar 2015 16:06:36 -0500 Received: from cantor2.suse.de ([195.135.220.15]:58745 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbbCGVGe (ORCPT ); Sat, 7 Mar 2015 16:06:34 -0500 Date: Sat, 7 Mar 2015 22:05:14 +0100 From: Borislav Petkov To: Yinghai Lu Cc: Ingo Molnar , Matt Fleming , "H. Peter Anvin" , Bjorn Helgaas , Thomas Gleixner , Ingo Molnar , Jiri Kosina , Baoquan He , Linux Kernel Mailing List , "linux-efi@vger.kernel.org" , "linux-pci@vger.kernel.org" , Kees Cook Subject: Re: [PATCH v2 04/15] x86, kaslr: get kaslr_enabled back correctly Message-ID: <20150307210514.GC3380@pd.tnic> References: <1425456048-16236-1-git-send-email-yinghai@kernel.org> <1425456048-16236-5-git-send-email-yinghai@kernel.org> <20150304101649.GA3663@pd.tnic> <20150304200000.GB6276@gmail.com> <20150306133312.GC4259@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote: > That will get wrong value back for kaslr_enabled in kernel stage. > 1. When kaslr is not enabled at boot/choose_kernel_location, if kaslr_enabled > get set wrongly in setup.c, late in module.c::get_module_load_offset > will return not wanted random module load offset. > That change behavior when HIBERNATION is defined or nokaslr is passed. > > 2. When kaslr is enabled at boot/choose_kernel_location, if kaslr_enabled > get cleared wrongly in setup.c, late in module.c::get_module_load_offset > will not return wanted random module load offset. Now you went from the one extreme to the other. Initially it was "trivial and obvious" now it is too much unreadable detail which no one needs. How about this: --- Commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation") started passing KASLR status to kernel proper, but it uses a physical address as the vaule, leading to parsing bogus KASLR status in kernel proper. The setup_data linked list and thus the element which contains kaslr_enabled is chained together using physical addresses. At the time when we access it in the kernel proper, we're already running with paging enabled and therefore must access it through its virtual address. This patch changes the code to use early_memmap() and access the value. --- Complaints? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --