From patchwork Fri Sep 8 19:52:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 811816 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3xpnzR41Lsz9sCZ; Sat, 9 Sep 2017 05:52:35 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dqPKI-0004gk-O7; Fri, 08 Sep 2017 19:52:30 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1dqPKG-0004gI-VC for kernel-team@lists.ubuntu.com; Fri, 08 Sep 2017 19:52:28 +0000 Received: from mail-qt0-f197.google.com ([209.85.216.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1dqPKG-0005EC-LY for kernel-team@lists.ubuntu.com; Fri, 08 Sep 2017 19:52:28 +0000 Received: by mail-qt0-f197.google.com with SMTP id h15so4531477qta.4 for ; Fri, 08 Sep 2017 12:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id; bh=8wlCighdYIbNPjnkJSAurLyadGb0kN6c/+sj3iQSd/Q=; b=orzExGpCqTo+N9XOtCcrwdpsfLXeBpJNe+z/mhKsjTY6IrQ9NPAKK20sgnn1fwqmJy s8Y8h+zJ8N5DRJEWcCp00jODI7BQ1o7YwqYQdO6enLobTM2axCCWqxgC4PTXs5BShR/n aP/p+MhlJUfAYpykQ5JOKdPlN2nrYpXfO3953dbwzSzRrlsIl7h4b0iSyGMNxJJTVkPZ yGF2MYcxZ6NgqUh4zzc87Hi8uHGLqYqe6ubZ245u+VvWiZdb/eL7GgfB4i4WjjTExsxk uYTEKLtWSSanCkU6qFjJHsbRrbDx2Lt6tns2/6pn/Yg7gldPyPSTHRFR9jFxh2GO+vaE kwEQ== X-Gm-Message-State: AHPjjUi32jGIqsknilXSj7r03wHLOTepgjlmgSzXA/MASiSejTLrTYQi JWbFh1LLkEatxdq4r/lrCKZyocmq7WQLr3qUOPB3tVakO/0piA7jfId5xG7SJ6DyrflisFvZVuU O3OIzCFfFg9ugzEIFDq0rcxvAbScxKrMK X-Received: by 10.55.157.195 with SMTP id g186mr5128207qke.347.1504900347617; Fri, 08 Sep 2017 12:52:27 -0700 (PDT) X-Google-Smtp-Source: AOwi7QA/iisekBnz5OcCSHx5uyTsoWQyMvqYlz7GxwvBS+jcXUzizgIRXZ/EkPnWSCfu7jyqGHBN5g== X-Received: by 10.55.157.195 with SMTP id g186mr5128186qke.347.1504900347341; Fri, 08 Sep 2017 12:52:27 -0700 (PDT) Received: from localhost.localdomain ([177.68.179.170]) by smtp.gmail.com with ESMTPSA id k2sm1748393qtk.53.2017.09.08.12.52.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Sep 2017 12:52:26 -0700 (PDT) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [azure][PATCH] x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails Date: Fri, 8 Sep 2017 16:52:17 -0300 Message-Id: <1504900337-21269-1-git-send-email-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.7.4 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Baoquan He BugLink: http://bugs.launchpad.net/bugs/1702515 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 (cherry picked from commit da63b6b20077469bd6bd96e07991ce145fc4fbc4) Signed-off-by: Marcelo Henrique Cerri Acked-by: Colin Ian King Acked-by: Marcelo Henrique Cerri --- arch/x86/boot/compressed/kaslr.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c index 8fad8a64d670..1199a74f867c 100644 --- a/arch/x86/boot/compressed/kaslr.c +++ b/arch/x86/boot/compressed/kaslr.c @@ -594,10 +594,17 @@ void choose_random_location(unsigned long input, 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))