lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20191024171417.14175-1-kasong@redhat.com>
Date:   Fri, 25 Oct 2019 01:14:17 +0800
From:   Kairui Song <kasong@...hat.com>
To:     linux-kernel@...r.kernel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Thomas Lendacky <Thomas.Lendacky@....com>,
        Baoquan He <bhe@...hat.com>, Dave Young <dyoung@...hat.com>,
        x86@...nel.org, Kairui Song <kasong@...hat.com>
Subject: [PATCH] x86/kdump: Print a notice if SME/SEV is active on crash reservation

SME/SEV requires SWIOTLB to be force enabled in both first kernel
and kdump kernel, the detail is covered in following 3 commits:

- commit c7753208a94c ("x86, swiotlb: Add memory encryption support")
force enables SWIOTLB when SME is active, even if there is less than
4G of memory, to support DMA of devices that not support address with
the encrypt bit.

- commit aba2d9a6385a ("iommu/amd: Do not disable SWIOTLB if SME is active")
kernel keep SWIOTLB enabled even if there is an IOMMU, to support special
devices that IOMMU can't handle.

- commit d7b417fa08d1 ("x86/mm: Add DMA support for SEV memory encryption")
force enables SWIOTLB when SEV is active unconditionally.

Force enabling SWIOTLB in kdump kernel will make it easily run out of
already scarce pre-reserved crashkernel memory.

The crashkernel value is user specified, and kernel should respect the
given value to make the behavior clear and controllable. And currently
there is no way kernel could estimate the crashkernel value after all.

So when SME/SEV is active, just print a notice to let the user know the
situation and adjust the crashkernel value accordingly. Suppress the
notice if high reservation is used, as high reservation will always
reserve a dedicated low memory region which will cover the SWIOTLB.

Signed-off-by: Kairui Song <kasong@...hat.com>
---
 arch/x86/kernel/setup.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 77ea96b794bd..d5ceea03c0a3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -594,6 +594,13 @@ static void __init reserve_crashkernel(void)
 		return;
 	}
 
+	if (crash_base < (1ULL << 32) && mem_encrypt_active()) {
+		pr_notice("Memory encrytion is active, SWIOTLB is required to work,\n"
+			  "%luMB of low crash memory will be consumed by it.\n"
+			  "Please ensure crashkernel value is large enough.\n",
+			  (ALIGN(swiotlb_size_or_default(), SZ_1M) >> 20));
+	}
+
 	pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System RAM: %ldMB)\n",
 		(unsigned long)(crash_size >> 20),
 		(unsigned long)(crash_base >> 20),
-- 
2.21.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ