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>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201207061227.131580-1-ying-tsun.huang@amd.com>
Date:   Mon,  7 Dec 2020 14:12:26 +0800
From:   Ying-Tsun Huang <ying-tsun.huang@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Ying-Tsun Huang <ying-tsun.huang@....com>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Toshi Kani <toshi.kani@...com>, linux-kernel@...r.kernel.org
Cc:     Dmitry Lapik <dmitry.kolyadintsev@...iad.com>,
        James Lee <James.Lee@....com>
Subject: [PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.

In mtrr_type_lookup, if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is mapped to the physical memory actually.

However, if the end address is just aligned with the top of memory,
the condition check treats the address is over the top of memory, and
write-back attribute is not returned.

There is a real case of NVDIMM. The nd_pmem module tries to map
NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM
is the last of the DIMMs, the performance of this NVDIMM becomes very
low since it aligned with the top of memory and its memory type is
uncached-minus.

To check the top of memory should use "<=" instead of "<" since both the
input end address and the value of top of memory are actually the start
of next region.

Fixes: b73522e0c1be ("x86/mm/mtrr: Enhance MTRR checks in kernel mapping
helpers")
Signed-off-by: Ying-Tsun Huang <ying-tsun.huang@....com>
---
 arch/x86/kernel/cpu/mtrr/generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 23ad8e953dfb..b13e87dba27d 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -303,7 +303,7 @@ u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
 			goto out;
 	}
 
-	if (mtrr_tom2 && (start >= (1ULL<<32)) && (end < mtrr_tom2))
+	if (mtrr_tom2 && (start >= (1ULL<<32)) && (end <= mtrr_tom2))
 		type = MTRR_TYPE_WRBACK;
 
 out:
-- 
2.25.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ