Received: by 10.213.65.68 with SMTP id h4csp270550imn; Fri, 23 Mar 2018 04:24:02 -0700 (PDT) X-Google-Smtp-Source: AG47ELt9xRN3FoWUiVvbDfWLYo6EF8vilxS4QXc6IRv9v6/Jl9uexbivkURrXASHuY/Zb8GACmbm X-Received: by 2002:a17:902:7b81:: with SMTP id w1-v6mr5183392pll.66.1521804242940; Fri, 23 Mar 2018 04:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521804242; cv=none; d=google.com; s=arc-20160816; b=GKecz+fW1MoIoqrOA7P2789ODpOPx91aMXppZx6KaPnXNOaJc/bYVkOZulgEEoaMl9 6YjRyCCrJi2jDXY7PnzRduw+U/uqmCnooTJ2fEfabyIcPbBBGQVO2kE+HOaIIaGogjmD BXL1YNjNi9x1apzaDS5kYiv3DPYEiXHI4x3eKPI5i2lGKpDJpkLaNDOzXq9OJ1qNY8+r TO6xKBrRisNnIm6RqsSbnOTQyLp8Iy7MhFvIiCXikuYPlRstDUbacPsnX0TBKLGmaqKF Nt6GS902tOwahz+J/l0t4+35fo4YwCeQOlknX0VoWSa6D6vgUQ93dMuQGyE81rYPnYaf VImQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=HrWLyeU8QebQknu7kXnZeNaug+h9GUABWxv+xrBh5sQ=; b=F5THajqPPtkE2E2OD+daJPvp8x0RTVAR5rM4QyY+zf0zC8I39TMQG1Rs8/ypU1Y9qu 5/5+N30QO0ag9gQt06gewP0QlXkPwv8ChpzJEwIRCZpVzXsym/JaqLm1EOCHT8trwnnn 9SzQGjoNQWV+L12yar9QBkXm7peMQHT/JIAX9h3lEpVZy9tsFbsXitRqUuP0BxVc+3iT I9ttukXnn2h21lTt08FdBQuvsyIYdOp/O0GlA7DR/FeTBCedtk1wj7BBj5ZNhVd8u8yo F60tQqIlw/fndps8octTruyQiTNz+M425e3//TNNgPPSdLHKYLpYxCjI7OB3sQot/9f+ zoig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e16si6740338pfd.6.2018.03.23.04.23.48; Fri, 23 Mar 2018 04:24:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755452AbeCWKIF (ORCPT + 99 others); Fri, 23 Mar 2018 06:08:05 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41460 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755416AbeCWKH4 (ORCPT ); Fri, 23 Mar 2018 06:07:56 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 2D2DED8B; Fri, 23 Mar 2018 10:07:55 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Baoquan He , Dave Young , Kees Cook , Borislav Petkov , Dave Jiang , Linus Torvalds , Peter Zijlstra , Thomas Garnier , Thomas Gleixner , Yinghai Lu , Ingo Molnar , Sasha Levin Subject: [PATCH 4.9 086/177] x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails Date: Fri, 23 Mar 2018 10:53:34 +0100 Message-Id: <20180323094209.091700840@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094205.090519271@linuxfoundation.org> References: <20180323094205.090519271@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baoquan He [ Upstream commit da63b6b20077469bd6bd96e07991ce145fc4fbc4 ] Dave found that a kdump kernel with KASLR enabled will reset to the BIOS immediately if physical randomization failed to find a new position for the kernel. A kernel with the 'nokaslr' option works in this case. The reason is that KASLR will install a new page table for the identity mapping, while it missed building it for the original kernel location if KASLR physical randomization fails. This only happens in the kexec/kdump kernel, because the identity mapping has been built for kexec/kdump in the 1st kernel for the whole memory by calling init_pgtable(). Here if physical randomizaiton fails, it won't build the identity mapping for the original area of the kernel but change to a new page table '_pgtable'. Then the kernel will triple fault immediately caused by no identity mappings. The normal kernel won't see this bug, because it comes here via startup_32() and CR3 will be set to _pgtable already. In startup_32() the identity mapping is built for the 0~4G area. In KASLR we just append to the existing area instead of entirely overwriting it for on-demand identity mapping building. So the identity mapping for the original area of kernel is still there. To fix it we just switch to the new identity mapping page table when physical KASLR succeeds. Otherwise we keep the old page table unchanged just like "nokaslr" does. Signed-off-by: Baoquan He Signed-off-by: Dave Young Acked-by: Kees Cook Cc: Borislav Petkov Cc: Dave Jiang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Garnier Cc: Thomas Gleixner Cc: Yinghai Lu Link: http://lkml.kernel.org/r/1493278940-5885-1-git-send-email-bhe@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/x86/boot/compressed/kaslr.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/arch/x86/boot/compressed/kaslr.c +++ b/arch/x86/boot/compressed/kaslr.c @@ -460,10 +460,17 @@ void choose_random_location(unsigned lon add_identity_map(random_addr, output_size); *output = random_addr; } + + /* + * This loads the identity mapping page table. + * This should only be done if a new physical address + * is found for the kernel, otherwise we should keep + * the old page table to make it be like the "nokaslr" + * case. + */ + finalize_identity_maps(); } - /* This actually loads the identity pagetable on x86_64. */ - finalize_identity_maps(); /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */ if (IS_ENABLED(CONFIG_X86_64))