linux-kernel - [PATCH v4] x86, kaslr: Access the correct kaslr

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: <1426405767-21100-1-git-send-email-yinghai@kernel.org>
Date:	Sun, 15 Mar 2015 00:49:27 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Borislav Petkov <bp@...e.de>, Baoquan He <bhe@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>
Subject: [PATCH v4] x86, kaslr: Access the correct kaslr_enabled variable

While trying to optimize setup_data handling code, found commit f47233c2d34f
("x86/mm/ASLR: Propagate base load address calculation"), uses a physical
address as the value.

It leads to wrong kaslr status. That kaslr status is passed for controlling
module load offset. So when kernel has kasl support compiled in, and user
use nokaslr to disable kaslr, wrong value cause unwanted offset for module
loading.

We should keep kaslr status consistent between aslr randrom kernel base,
and late module random offset. That is old behavior before that commit.

The setup_data linked list and thus the element which contains
kaslr_enabled is chained together using physical addresses. At the time
when we access it in the kernel, we're already running with paging enabled
and therefore must access it through its virtual address.

This patch changes the code to use early_memmap() and access the value,
as it is still in kernel early stage, we don't have kernel mapping setup
yet.

Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
Cc: Matt Fleming <matt.fleming@...el.com>
Cc: Borislav Petkov <bp@...e.de>
Cc: Kees Cook <keescook@...omium.org>
Cc: Jiri Kosina <jkosina@...e.cz>
Acked-by: Jiri Kosina <jkosina@...e.cz>
Signed-off-by: Yinghai Lu <yinghai@...nel.org>

---
-v3: add checking return from early_memmap according to Boris.
-v4: add description about setup_data accessing from Boris to change log.

---
 arch/x86/kernel/setup.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -429,7 +429,18 @@ static void __init reserve_initrd(void)

 static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
 {
-	kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
+	/* kaslr_setup_data is defined in aslr.c */
+	unsigned char *data;
+	unsigned long offset = sizeof(struct setup_data);
+
+	data = early_memremap(pa_data, offset + 1);
+	if (!data) {
+		kaslr_enabled = true;
+		return;
+	}
+
+	kaslr_enabled = *(data + offset);
+	early_memunmap(data, offset + 1);
 }

 static void __init parse_setup_data(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/