[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2017 12:02:47 +0200
From: Daniel Gruss <daniel.gruss@...k.tugraz.at>
To: kernel list <linux-kernel@...r.kernel.org>,
<kernel-hardening@...ts.openwall.com>
CC: "clementine.maurice@...k.tugraz.at" <clementine.maurice@...k.tugraz.at>,
"moritz.lipp@...k.tugraz.at" <moritz.lipp@...k.tugraz.at>,
Michael Schwarz
<michael.schwarz@...k.tugraz.at>,
Richard Fellner
<richard.fellner@...dent.tugraz.at>,
<kirill.shutemov@...ux.intel.com>, "Ingo
Molnar" <mingo@...nel.org>,
"anders.fogh@...ta-adan.de"
<anders.fogh@...ta-adan.de>
Subject: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
After several recent works [1,2,3] KASLR on x86_64 was basically
considered dead by many researchers. We have been working on an
efficient but effective fix for this problem and found that not mapping
the kernel space when running in user mode is the solution to this
problem [4] (the corresponding paper [5] will be presented at ESSoS17).
With this RFC patch we allow anybody to configure their kernel with the
flag CONFIG_KAISER to add our defense mechanism.
If there are any questions we would love to answer them.
We also appreciate any comments!
Cheers,
Daniel (+ the KAISER team from Graz University of Technology)
[1] http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
[2]
https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf
[3]
https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
[4] https://github.com/IAIK/KAISER
[5] https://gruss.cc/files/kaiser.pdf
View attachment "0001-KAISER-Kernel-Address-Isolation.patch" of type "text/x-patch" (22363 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
