Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935411Ab3DPCbr (ORCPT ); Mon, 15 Apr 2013 22:31:47 -0400 Received: from terminus.zytor.com ([198.137.202.10]:34740 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935111Ab3DPCbq (ORCPT ); Mon, 15 Apr 2013 22:31:46 -0400 Message-ID: <516CB7EE.8070702@zytor.com> Date: Mon, 15 Apr 2013 19:31:10 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Kees Cook CC: Eric Northup , Yinghai Lu , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , Jarkko Sakkinen , Matthew Garrett , Matt Fleming , Dan Rosenberg , Julien Tinnes , Will Drewry Subject: Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot References: <1365797627-20874-1-git-send-email-keescook@chromium.org> <1365797627-20874-7-git-send-email-keescook@chromium.org> <516A1D49.1050100@zytor.com> <516C702C.2030209@zytor.com> <516C751B.4020505@zytor.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1695 Lines: 47 On 04/15/2013 02:59 PM, Kees Cook wrote: >> >> The *physical* mapping, where it lands in RAM, is completely >> independent, and if you're going to randomize the latter, there is no >> reason it has to match the former. Instead, randomize it freely. > > Ah, gotcha. I don't see much benefit in doing this as it would make > the 32-bit and 64-bit logic pretty different without much real-world > gain, IMO. > You *have* to make them different anyway. Otherwise you aren't really doing anything useful on x86-64. Seriously, do it right if anything. I also am starting to think that this really would be done better being integrated with the decompressor code, since that code already ends up moving the code around... no reason to do this again. >> That is different from the i386 kernel which runs at its >> physical-mapping address. >> >> Incidentally, for performance reasons please avoid locating the kernel >> below CONFIG_PHYSICAL_ADDRESS if possible. > > You mean CONFIG_PHYSICAL_START? This is already done in aslr.S via > LOAD_PHYSICAL_ADDR which is calculated from the > CONFIG_PHYSICAL_ALIGN-masked CONFIG_PHYSICAL_START. > >> Also make sure your code works with more than 128 e820 entries. > > There should be no problem here; we're using edi to count them. More than 128 entries are fed via a different protocol. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/