Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751260AbcDPImi (ORCPT ); Sat, 16 Apr 2016 04:42:38 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34223 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751109AbcDPImf (ORCPT ); Sat, 16 Apr 2016 04:42:35 -0400 Date: Sat, 16 Apr 2016 10:42:28 +0200 From: Ingo Molnar To: Kees Cook Cc: Baoquan He , Yinghai Lu , Ard Biesheuvel , Matt Redfearn , "x86@kernel.org" , "H. Peter Anvin" , Ingo Molnar , Borislav Petkov , Vivek Goyal , Andy Lutomirski , lasse.collin@tukaani.org, Andrew Morton , Dave Young , "kernel-hardening@lists.openwall.com" , LKML , Linus Torvalds , Thomas Gleixner Subject: Re: [PATCH v5 03/21] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Message-ID: <20160416084228.GA30071@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-4-git-send-email-keescook@chromium.org> <20160415080715.GD30715@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Content-Length: 1231 Lines: 31 * Kees Cook wrote: > > Also note the assertive tone: if this Kconfig feature is eanbled, we say that > > the kernel address _will_ be randomized, and we should make sure it is. (If > > for some weird reason randomization fails we should warn prominently during > > bootup.) > > This will need some thought... is it better to fail to boot or to boot without > entropy? As-is, it's possible to randomly position the kernel base address at > exactly the location it was going to boot without KASLR too, yet this is still > considered random... I think we should boot but print a prominent warning. On real systems it's not supposed to happen, right? So we want to know if it happens, but don't want to hassle the user with breaking the system by not booting. > > Also, could we always mix the i8254 timer into this as well, not just when > > RDTSC is unavailable? > > IIRC, hpa explicitly did not want to do this when he was making > suggestions on this area. I would need to dig out the thread -- I > can't find it now. I'd prefer to leave this as-is, since changing it > would add yet another variable to the behavioral changes of this > series. Sure, can stay as-is for now. Thanks, Ingo