linux-kernel - [PATCH v2] x86/mtrr: Correct the returned MTRR type of mtrr_type

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]

Date:   Tue, 15 Dec 2020 15:07:20 +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>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Ying-Tsun Huang <ying-tsun.huang@....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 v2] 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.

The input end address should be changed to inclusive to be checked
for the top of memory.

Fixes: 0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()")
Signed-off-by: Ying-Tsun Huang <ying-tsun.huang@....com>
---
 arch/x86/kernel/cpu/mtrr/generic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 23ad8e953dfb..a29997e6cf9e 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -167,9 +167,6 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end,
 	*repeat = 0;
 	*uniform = 1;

-	/* Make end inclusive instead of exclusive */
-	end--;
-
 	prev_match = MTRR_TYPE_INVALID;
 	for (i = 0; i < num_var_ranges; ++i) {
 		unsigned short start_state, end_state, inclusive;
@@ -261,6 +258,9 @@ u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
 	int repeat;
 	u64 partial_end;

+	/* Make end inclusive instead of exclusive */
+	end--;
+
 	if (!mtrr_state_set)
 		return MTRR_TYPE_INVALID;

-- 
2.25.1