Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.