Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753840AbdDJSN1 (ORCPT ); Mon, 10 Apr 2017 14:13:27 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:32912 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752911AbdDJSNY (ORCPT ); Mon, 10 Apr 2017 14:13:24 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Kees Cook Date: Mon, 10 Apr 2017 11:13:12 -0700 X-Google-Sender-Auth: Ia54i2vTbBVRQuD6FktfMy_Tnvo Message-ID: Subject: Re: KASLR causes intermittent boot failures on some systems To: Jeff Moyer Cc: Thomas Garnier , Ingo Molnar , Baoquan He , Dan Williams , LKML , linux-nvdimm@ml01.01.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1099 Lines: 28 On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote: > Kees Cook writes: > >> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote: >>> Hi, >>> >>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory >>> regions") causes some of my systems with persistent memory (whether real >>> or emulated) to fail to boot with a couple of different crash >>> signatures. The first signature is a NMI watchdog lockup of all but 1 >>> cpu, which causes much difficulty in extracting useful information from >>> the console. The second variant is an invalid paging request, listed >>> below. >> >> Just to rule out some of the stuff in the boot path, does booting with >> "nokaslr" solve this? (i.e. I want to figure out if this is from some >> of the rearrangements done that are exposed under that commit, or if >> it is genuinely the randomization that is killing the systems...) > > Adding "nokaslr" to the boot line does indeed make the problem go away. Are you booting with a memmap= flag? -Kees -- Kees Cook Pixel Security