[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC562305B2AC@ORSMSX103.amr.corp.intel.com>
Date: Fri, 10 Feb 2017 19:02:42 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>
CC: Kees Cook <keescook@...omium.org>
Subject: %pK continuation
I haven't had time to really work on the continuation of:
http://www.openwall.com/lists/kernel-hardening/2016/10/07/1
I think the simple approach of killing %p based on kptr_restrict remains the simplest, IMHO best way to achieve a better level of
preventing leaks of kernel addresses. In example of %pK going wrong can be found here:
https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html.
Granted, the exploit author would have found another way to defeat KASL, I'd like to force their hand.
In a nut shell, the driver use %pk instead of %pK (capitalization of K matters). This would actually be a
good checkpatch.pl check. I grep'd the kernel for %pk (lower case k) and found no usages!
Just passing along some thoughts,
Bill
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.
