Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC562305F429@ORSMSX103.amr.corp.intel.com>
Date: Mon, 13 Feb 2017 19:50:00 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: Kees Cook <keescook@...omium.org>
CC: "kernel-hardening@...ts.openwall.com"
	<kernel-hardening@...ts.openwall.com>
Subject: RE: %pK continuation



> -----Original Message-----
> From: keescook@...gle.com [mailto:keescook@...gle.com] On Behalf Of Kees
> Cook
> Sent: Friday, February 10, 2017 3:42 PM
> To: Roberts, William C <william.c.roberts@...el.com>
> Cc: kernel-hardening@...ts.openwall.com
> Subject: Re: %pK continuation
> 
> On Fri, Feb 10, 2017 at 11:02 AM, Roberts, William C
> <william.c.roberts@...el.com> wrote:
> > 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.
> 
> There's been some experimentation in Android kernels recently based on your
> original version, though it's not quite ready for prime-time. I'm hoping to see it
> posted to this list soon...

Oh really, do you have any links to those patches?

> 
> > Granted, the exploit author would have found another way to defeat KASL, I'd
> like to force their hand.
> 
> Always true, but better to keep raising the bar, I think. :)
> 
> -Kees
> 
> --
> Kees Cook
> Pixel Security

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.