From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A678A21A04817 for ; Mon, 10 Apr 2017 11:13:14 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id a103so41799695ioj.1 for ; Mon, 10 Apr 2017 11:13:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Kees Cook Date: Mon, 10 Apr 2017 11:13:12 -0700 Message-ID: Subject: Re: KASLR causes intermittent boot failures on some systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Jeff Moyer Cc: Baoquan He , linux-nvdimm@lists.01.org, LKML , Ingo Molnar , Thomas Garnier List-ID: 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 _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 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 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